#installer
1 messages ยท Page 1 of 1 (latest)
yey ^^
wow
Updated PR#147 to add --no-validate-record and --no-validate-file-content ๐
Removed that into a separate branch.
Thanks!
Wait what..?
Seemed that CI#517 requires an approval, and that blocks CI#518 which is required for auto-merging.
And that particular CI run for checking is already cancelled so the result of checks will never get returned ๐คฃ
So... Any chance for the PR to be merged today? (I think I definitely spammed quite a lot during the feedback cycle, sorry about that ๐)
Ok, that should do it.
All checks have passed, let' s do this ๐
AH, I didn't realise my close-reopen also removed the auto-merge. ๐คฆ๐ปโโ๏ธ
So I'm planning to add CLI support for validate_record in the next few days.
However I'm wondering what the options should look like.
In 14cefe1 I made "validate all" the default strategy, and introduced --no-validate-record and --no-validate-file-content. However I think that's somewhat dirty, especially because the former will override the latter.
--validate-record=entries|contents|all|none
I just submitted https://github.com/pypa/installer/pull/161.
Thoughts: metavar needs a better name, and the test too. (Extra tests for "illegal" wheels?)
Bug or Feature? ๐ https://github.com/python-poetry/poetry/issues/7572#issuecomment-1447608308
Poetry version: 1.4.0 Python version: 3.11 OS version and name: macOS 13.2.1/MacPorts pyproject.toml: https://gist.github.com/elventear/2410f2f8a05926df27488767cfcab780 I am on the latest stable Po...
I need to cut a release. ๐
Please do ๐
I'll put my hands on #156 in the next few days, been busy experimenting Rust and forgot about that...
@vestal delta about that release?
I think his task queue is rather long
And I think leaving incomplete #156 there would somehow block the release...
https://github.com/pypa/installer/pull/167
This addresses #156.
documentation needs to present an example and add cross-references to/from WheelSource.validation_error.
Not sure about documentation though...
Indeed. Thanks for picking that up!
I just cut a release of installer. Lemme know if there's something needed/missing from it!
๐
this poetry issue may be related to installer, but I'm not certain https://canary.discord.com/channels/487711540787675139/1087094619906523230
I took a look at #172 today, and had some thoughts on it.
We can resolve target_path and dir_to_embed as a list[tuple[str, str], then we pass that to _perform_compilation, which uses python -c with a short script to call compileall. The resolved content is passed as serialized json.
Is there any hidden issue with this approach?
Also we can use heuristics to use compileall module directly, if installer and target interpreters are the same.
I was thinking of a -c script that reads from stdin and calls pycompile on the file given to it.
Basically, doing what we're doing already, except using stdin and a "worker" subprocess for performing the compilation.
And, sticking to the current logic on interpreter==sys.executable
We don't really need any feedback other than a failure to compile a file.
I have finished initial implementation, however I'm not sure whether we need to use shutil.which or something to "find python" when the interpreter passed in is not accurate.
And I'm thinking about how to test that...
Let's say I have an empty environment with no packages, including pip, but I have an installer wheel. How do I install installer so that I can start installing other wheels?
You could set PYTHONPATH to the installer wheel path and then use python -m installer to make installer install itself.
Awesome, looks like that worked! I didn't realized you could put a wheel directly on the path (maybe just a pure python wheel?)
I believe it's not really supported, because the structure of a wheel is not exactly like that of an installed project. But it's close enough that in a lot of cases it works anyway.
I guess that also means I don't actually need to install installer into my environment
Putting a wheel in path is guaranteed to work if the wheel is structured specifically to follow PEP 273. Modern build systems generally build pure-Python wheels to be compatible. (And indeed non-pure-Python wheels cannot work due to PEP 273 disallowing dynamic modules.)
Oh, another caveat is the Python environment must support the decompression algorithm used by the wheel (generally deflate so you need zlib)
Is there a way to install multiple wheels at once with the built-in CLI? I don't think so but just want to make sure I'm not missing it
I don't think so, but I think it could be added
I think it's as simple as setting nargs='+' and then iterating over the wheels, right? https://github.com/pypa/installer/blob/main/src/installer/__main__.py#L18. None of the other flags seem like they'd only apply to a single wheel.
yeah, that and probably some "for each do" operation
Any plans for a new release soon? I'd love to start using the multi-wheel feature.
I think yes, we just have to figure out the launchers
ah, windows
yeah
Windows -.-
What's missing there?
we are syncing with distlib on that, but there was a change in what binaries they ship
... or maybe I'll just move to uv pip install? ๐
maybe
yeah
at the same time, some complain ["why is windows support not a hard requirement"](#pip message)
What's the issue with the launchers?
I ported them to GHA/meson a while back, but that never went anywhere I think: https://github.com/msys2-contrib/simple_launcher/tree/meson-ci
See https://bitbucket.org/vinay.sajip/simple_launcher/issues/9/ci-and-meson-support - GitHub - msys2-contrib/simple_launcher at meson-ci
I've set up trusted publishing configuration on PyPI.
The set of installers that we're downloading from simple_launcher is not the same as the installers in distlib; and our current logic also does not match either distlib or any other installer. The hope is to fix those so that things are handled correctly but I haven't had time to dig into these for a little while now (I did build a Windows box between then and now, so there's that!).
Hi, may I ask to be a maintainer of installer? some changes need to be made to support Python 3.13
@vestal delta
I also saw some requests(https://github.com/pypa/installer/issues/218) to support python 3.13. And I guess there should be some testing and cleanup to be done.
@sage dirge there is an issue of launcher scripts and keeping them up to date with distlib and pip. it's in @vestal deltas hands right now to review the PRs (there are 2 different solutions). other than that I didn't see any urgent PRs for 3.13 compatibility
yeah, i also noticed that 3.13 has undeprecated the importlib.resources APIs, no urgent issues
is this supported? https://packaging.python.org/en/latest/specifications/direct-url/
no. WheelFile expects a name of .whl file that it opens. You could implement your own version of that, using WheelSource as a base
small PR to reduce import time https://github.com/pypa/installer/pull/226
No, installer takes a wheel file, which doesn't have the info required by direct_url. You need to implement direct_url on top of it
already got that in the thread btw
Any ideas how to upstream fixes for simple_launcher? PRs are disabled and the maintainer seems busy. More context: https://github.com/msys2/MINGW-packages/pull/21436#issuecomment-2234262269
If vinay is open to moving this around, I am supportive of the idea!
I am up to help as well
@karmic pagoda since #pip is locked: any chance you or someone else from pip team could take a look at this issue and shed some light on what the sitauation looks like in pip nowadays (sysconfig vs distutils, deprecations, future plans etc)?
There is also this - what kind of special stuff does pip do over "standard" wheel installation?
TL;DR: trying to figure out how much work is there to make installer work like pip or at least to enable the special cases in some way
Uhhh, I'll try to get back to you in a few days, but frankly, I'm probably not the best person to ask.
no rush and no pressure - "I have no idea" is a perfectly fine answer. I was just hoping someone from pip side could have some insight into those matters
from my previous analysis, installer pretty much wraps up everything that pip does, but with some attempt at generalization so that others could in principle use it. For example, you have to tell it what installer-name string to write in the INSTALLER metadata file.
I doubt an explicit answer is written down anywhere for subtle differences; one would have to compare the linked wheel.py from the issue to the installer source
I suppose Pradyun might have something more specific in mind (having submitted the issues) but it's been a few years...
cc @vestal delta
Looking for some peer reviews for https://github.com/pypa/installer/pull/306 and https://github.com/pypa/installer/pull/305. Pradyun seems to be unavailable and there is a release to be done. I have the power of merging without approval, but would appreciate at least some eyes before I do so
Left a suggestion on the PR, you emptied the permissions (permissions: {}) and never gave the checkout step permission to clone the repo (contents: read)
Other than that these LGTM
hello, is there currently a timeline in place for a new release (looking at the above PRs to set up Trusted Publishing, I don't see any blockers there)? thanks!
The timeline is whenever I will find some time to bring it over the finish line. If I was to give any dates, I would say first half of March is "possible".
awesome, thanks โโ appreciate it!
Long overdue - https://pypi.org/project/installer/1.0.0/ installer 1.0 is now out.
Maybe, some security experts can take a look at https://github.com/pypa/installer/pull/326
Is it safe to use os.path.abspath() instead of Path.resolve() in this case? For details see the PR description.
@gleaming reef @novel hearth any chance you could share a cookie of security knowledge?
The docs for os.path.abspath() say it's normalized and absolutized, testing in Python and /../ is normalized out.
Is there a specific question needing a security POV?
concur with Seth, my recollection is that the difference between abspath and resolve is that abspath collapses path separators naively without regard for symlinks, whereas resolve actually does symlink resolution (which is why it's a lot slower)
