poetry: migrate to [email protected]

[henryiii]

poetry: migrate to [email protected]

[henryiii]

I think this is expecting python3 to be valid? Looks like it running on Python 3.5 from the error...

==> /usr/local/Cellar/poetry/1.1.11_1/bin/poetry --version
env: python3: No such file or directory

[henryiii]

Because this is not hardcoded in the shabang, it can't use python 3.10 until python3 is part of python 3.10. See #62910.

[SMillerDev]

We can use rewrite_shebang detected_python_shebang, "file"

[henryiii]

I thought the point of removing the exact homebrew python version was so that people could use homebrew poetry with whatever Python version they had set as python3, not tying it to homebrew python. (Didn't read the issue that carefully, and seemed a little silly to me to use homebrew poetry with non-homebrew python, but not strongly opinionated here)

(Guessing this would replace python3 with the full path again, though correct me if I'm wrong)

[carlocab]

I think the idea was to be able to use Homebrew Poetry with Homebrew Python 3.7 or 3.8. I don't think we want to rewrite the shebang here.

Things we could do:

1. Wait until [email protected] is ready to be made not-keg-only.
2. Add Homebrew [email protected] to PATH in the test block.

(1) might take a while. (2) means extra setup for some users, but that seems better than a crippled installation.

[henryiii]

(2) would mean "brew install poetry" on a fresh installation would install Python 3.10 and poetry with python3, which wouldn't trigger Python 3.9, which means no python3, so poetry would be broken. (1) seems better.

[carlocab]

It seems to work on Catalina and Mojave Big Sur though. I've thought of a third option:

Wrap the poetry binary in an env script that appends [email protected]'s bin to PATH. (It might be possible to skip the env script with some shebang voodoo; not sure.) That way it will always find a python3, but respect the user's choice of one if they have a preference.

[henryiii]

I expect Catalina and Mojave have python3 already, from the developer tools.

[henryiii]

If poetry can be pointed at different pythons, doesn't that apply to python 3.10 too? so if we leave it pointing at python3, we need to keep requiring the package that provides python3 ([email protected]), but users can use 3.10 just like they can use 3.7 and 3.8?

[carlocab]

Sorry, I meant Catalina and Big Sur, not Mojave. I thought that Mojave had python3 too. Maybe it's just too old?

[carlocab]

If poetry can be pointed at different pythons, doesn't that apply to python 3.10 too? so if we leave it pointing at python3, we need to keep requiring the package that provides python3 ([email protected]), but users can use 3.10 just like they can use 3.7 and 3.8?

Yes. I'm not sure our mixed-version-dependency audit understands this, though, which is an issue for formulae that use poetry but want to depend on [email protected]. Not too many of those, though, so I guess it's not too bad to wait.

[carlocab]

Pushed a fix. Added a label to build dependents from source to make sure this didn't break anything.

[henryiii]

Looks like python 3.5 is trying to run it on Ubuntu?

[carlocab]

Ah, yes. That's expected, since Python 3.5 will come before Python 3.10 in PATH. It seems we can do one (or several) of the following:

1. hardcode a Python version. This will cause regressions for users who now use poetry with a different Python version.
2. wait until [email protected] is not keg-only.
3. prepend [email protected]'s bin directory to PATH to fix the test. Users who have an old Python3 early in their PATH would have problems with this formula, but they already would have had these before the changes here. [*]
4. add some magic to the libexec/"bin/poetry" script that re-executes itself with Python3.10 if it finds it's being used with a Python that's too old.

2 and 4 probably cause the least pain for users, 2 is probably easiest for us, depending on how keen we are to get this running on Python3.10.

[*] This change would make this problem worse, because users who currently have an old Python3 after HOMEBREW_PREFIX/"bin" are fine, but won't be with this change.

[henryiii]

Given the feature of being unpinned from a Python version that is causing the problem allows a user to use Python 3.10 already, I'd think option 2 isn't that bad. I'm not against option 1, personally, either, as I see homebrew as only supporting the latest version, and older versions are only there as a workaround due to some packages not supporting newer versions yet. But it's okay with me if people need something different.

[branchvincent]

4 would look something like:

diff --git a/Formula/poetry.rb b/Formula/poetry.rb
index ae859e2d30f..81507a945d0 100644
--- a/Formula/poetry.rb
+++ b/Formula/poetry.rb
@@ -204,6 +204,7 @@ class Poetry < Formula
 
     # We don't hardcode Homebrew Python here on purpose. See
     # https://github.com/Homebrew/homebrew-core/issues/62910
+    python310 = Formula["[email protected]"].opt_bin/"python3"
     (libexec/"bin/poetry").atomic_write <<~PYTHON
       #!/usr/bin/env python3
       import sys
@@ -211,6 +212,10 @@ class Poetry < Formula
       sys.path.insert(0, "#{site_packages}")
       sys.path.insert(0, "#{vendor_site_packages}")
 
+      if sys.version_info[:2] < (3, 6):
+          import os
+          os.execv("#{python310}", ("#{python310}",) + tuple(sys.argv))
+
       if __name__ == "__main__":
           from poetry.console import main
           main()

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.