python@3.9: various improvements

[alebcay]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

I realize that it's generally bad practice to squish more than one thing into a commit/PR but in the interest of saving some CI time and only bumping the revision once, I've packed a number of things into here:

• Update setuptools to 51.1.1
• Update pip to 20.3.3
• Update wheel to 0.36.2
• Adjust regex for cleaning up old setuptools/pip/wheel versions to
  be more specific. I've yet to see an issue where this regex cleaned
  out some dist info for some package out of site_packages that
  starts with "setuptools" or "wheel", but better to patch this up now
  than to wait for some issue to occur.
• Patch ensurepip to use our updated setuptools/pip rather than the
  bundled one (useful for situations where people need ensurepip, e.g. in a venv - could be helpful for python: use built-in venv instead of virtualenv when installing formulae brew#10039 but is probably useful on its own too)
• Fix gdbm functionality regression via --with-dbmliborder=gdbm:ndbm

Naturally, if there's any part of the PR that we don't want, feel free to say so and we can cut that out (or split it into a separate PR for down the road) but I figured I'd first try for a one-shot wonder.

[fxcoudert]

Patch ensurepip to use our updated setuptools/pip rather than the bundled one

I'd like to understand the goal of that part better. Can you expand a bit?

[carlocab]

Since you're already bundling a number of changes together, it may also be worth preventing the pouring of Intel bottles while running Rosetta: #67713

[alebcay]

I'd like to understand the goal of that part better. Can you expand a bit?

All this does is provide an updated setuptools/pip for ensurepip. The primary benefit would that venvs created would be able to use the updated setuptools/pip rather than whatever version Python came bundled with.

During build, the Python source for ensurepip contains source for a particular version of setuptools/pip and builds wheels for them into the specified location. This patching replaces the wheels with updated ones and adjusts the __init__.py to use wheels for our specified versions of setuptools/pip.

Admittedly, it may not be a big enough benefit to warrant adding more cruft into the formula.

---

Since you're already bundling a number of changes together, it may also be worth preventing the pouring of Intel bottles while running Rosetta: #67713

I read through this issue briefly, but I'm still not sure exactly what our course of action is moving forward here.

[carlocab]

I read through this issue briefly, but I'm still not sure exactly what our course of action is moving forward here.

Me too, but I think it might be safe to conclude that the Intel Big Sur bottle is broken when it's poured in Rosetta. If this is the case, then, at minimum, we should stop pouring the Intel Big Sur bottle on Rosetta while we figure out a longer-term solution.

Of course, now I'm wondering why this report regarding python and Intel Big Sur bottles didn't emerge earlier. It would be nice if we could get a maintainer to reproduce the issue.

[fxcoudert]

Admittedly, it may not be a big enough benefit to warrant adding more cruft into the formula

Yes, that's what I'm wondering. The more complex and patched we make it, the harder it becomes to maintain.

[dtrodrigues]

I think patching ensurepip is a good idea it, especially if that means we can incorporate Homebrew/brew#10039 more easily. This reduces the bootstrapping needed for the virtualenv method and will remove ~40 lines from Homebrew/brew as well as the need to download and install possibly 5 resources. Even without changing how brew builds python formulae, I think it'll provide a more controlled user experience if python3 -m venv installs the pip and setuptools that homebrew is providing vs whatever happened to be bundled with python.

That being said, if it warrants further discussion I don't think it should block the updates to pip, setuptools, and wheel, here, so I can open a separate PR for just the ensurepip part when I have a chance.

[fxcoudert]

I'm killing the tests because we're not going to be able to use those bottles anyway, because of #67713

And, we might as well fix #67388 at the same time

[alebcay]

I can remove the stuff for ensurepip from this PR and we can visit it again at a later time. Does the regex adjustment in the postinstall block look alright?

And, we might as well fix #67388 at the same time

I've only skimmed this issue just now - is the fix just removing depends_on "gdbm" or is there more to it?

[carlocab]

or is there more to it?

There's an inreplace somewhere that needs to go.

[carlocab]

Oh, wait, no. Not inreplace. Just the test. Sorry, I mixed it up with the gdbm formula.

This might be a good test to add:

import dbm

with dbm.ndbm.open("test", "c") as db:
    db[b"foo \xbd"] = b"bar \xbd"
with dbm.ndbm.open("test", "r") as db:
    print(list(db.keys()) == [b"foo \xbd"])
    print(b"foo \xbd" in db)
    print(db[b"foo \xbd"] == b"bar \xbd")

It should output

True
True
True

It could probably be stripped down. Just took it from #67388.

[alebcay]

For now, I will adjust the formula to include the --with-dbmliborder=... build flag and add the example test into the test block. This will keep the dependency on gdbm for now. I feel like some further discussion may be necessary for deciding if we want to stick with gdbm or proceed without it as a dependency (after briefly reading the updates on that issue). I will defer on that decision and just focus on addressing the immediate problem for now.

Holding off on any changes until #67853 goes through.

[dtrodrigues]

With #67853 merged, is there anything else needed for this PR?

[carlocab]

Don't think so. Probably good to ship it sooner rather than later, as it contains a bug fix.

[alebcay]

With #67853 merged, is there anything else needed for this PR?

No, should be fine right now. I waited for that merge because the revision bumps would have conflicted/been overwritten.

[BrewTestBot]

@carlocab has triggered a merge.

[carlocab]

Documented CI failures at #66450 (comment).