Maneage - Tasks: task #16268, python: bdist_wheel + installer...
You are not allowed to post comments on this tracker with your current authentication level.
task #16268: python: bdist_wheel + installer instead of egg
Submitter: | Boud Roukema <boud> | ||
Submitted: | Sun 25 Sep 2022 03:08:34 PM UTC | ||
Should Start On: | Sun 25 Sep 2022 12:00:00 AM UTC | Should be Finished on: | Sun 25 Sep 2022 12:00:00 AM UTC |
Category: | None | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Percent Complete: | 0% | Assigned to: | None |
Open/Closed: | Open | Effort: | 0.00 |
Tue 04 Oct 2022 09:02:54 PM UTC, comment #4: |
Eli Schwartz <eschwartz> |
Mon 03 Oct 2022 08:05:32 AM UTC, comment #3: Further discussion at #python on Libera Chat led to the general feeling that python developers have multiple ideas on how to improve python packaging. After several discussions and some reading, my impression was that E Schwartz (ztrawhcse)'s recommendations for 'bdist_wheel' and 'installer' made the best sense for Maneage. The strategy based on bdist_wheel is summarised in 'python.mk' in commit d5775fa [2] so that people who go directly to python.mk understand the (current) strategy.
|
Boud Roukema <boud>![]() |
Mon 26 Sep 2022 09:50:54 AM UTC, comment #2: It might solve the bug #63054, but that wasn't my intention.
|
Boud Roukema <boud>![]() |
Mon 26 Sep 2022 08:19:04 AM UTC, comment #1: Do you mean that with the option '--single-version-externally-managed' bug #63054 would be fixed? I could check it. |
Raul Infante-Sainz <infantesainz>![]() |
Sun 25 Sep 2022 03:08:34 PM UTC, original submission:
On the Libera Chat channel #python, when I asked a specific question in trying to find a simple workaround for the pyerfa bug #63054 [0], Chris Warrick described 'egg' format as 'legacy packaging format that should be avoided', and instead recommended us considering an update of our build rules [1].
although apparently a root option '--root=/SOME/PATH' could be useful too.
|
Boud Roukema <boud>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2022-10-03 | boud | Summary | python: -single-version-externally-managed instead of egg | ![]() |
python: bdist_wheel + installer instead of egg |
Yeah, python's ecosystem is in a bit of... flux. It's not always obvious what groups such as distros can do if "simply use pip install for everything" isn't a suitable answer -- and honestly, it never is a good answer.
My suggestion for bdist_wheel and installer is based on an understanding that the PyPA really, really want to push wheels, and this is not going away... after a lot of effort, installer actually exists these days and can serve as a baseline for installing those wheels in a simple, minimally bootstrapped, reproducible fashion. So, that's a good change to build on and helps the current situation a lot.
How to create wheel files is a lot more confusing. Pip creates them as a matter of course, and each PEP 517 build backend may have its own CLI for creating them, or recommend other methods. For setuptools, this is currently "python setup.py bdist_wheel" as a side migration from "python setup.py install". Setuptools is also deprecating setup.py install, and some other frontend commands, but it's not clear what the timeline for dropping support for that may be, if anything.
But making this change should solve real issues today, while simultaneously making it easier to switch to some other method later on, as python packaging requirements and recommendations settle. Which is good.
...
As noted, bootstrapping setuptools+installer itself would still involve some circularity, which is unfortunate, but the python standards groups do not seem to be focused on that use case.
Excluding those from the new installation method is reasonable and can be incrementally improved later, as the problem becomes better understood (maybe even by upstream, we can hope).