#installer

1 messages ยท Page 1 of 1 (latest)

vestal delta
#

Alrighty, I guess a good start to the history of this channel is me announcing that installer 0.6.0 is up on PyPI. :)

granite stag
#

yey ^^

sage dirge
#

wow

calm pewter
#

Updated PR#147 to add --no-validate-record and --no-validate-file-content ๐Ÿ˜‰

calm pewter
#

Removed that into a separate branch.

vestal delta
#

Thanks!

calm pewter
#

Wait what..?

#

Seemed that CI#517 requires an approval, and that blocks CI#518 which is required for auto-merging.

vestal delta
#

LOL

#

I clicked approve.

calm pewter
#

And that particular CI run for checking is already cancelled so the result of checks will never get returned ๐Ÿคฃ

calm pewter
#

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 ๐Ÿ™)

vestal delta
#

Ok, that should do it.

calm pewter
#

All checks have passed, let' s do this ๐Ÿš€

vestal delta
#

AH, I didn't realise my close-reopen also removed the auto-merge. ๐Ÿคฆ๐Ÿปโ€โ™‚๏ธ

calm pewter
#

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.

vestal delta
#

--validate-record=entries|contents|all|none

calm pewter
somber bridge
vestal delta
#

I need to cut a release. ๐Ÿ™ˆ

granite stag
#

Please do ๐Ÿ™

calm pewter
#

I'll put my hands on #156 in the next few days, been busy experimenting Rust and forgot about that...

granite stag
#

@vestal delta about that release?

calm pewter
#

I think his task queue is rather long

#

And I think leaving incomplete #156 there would somehow block the release...

calm pewter
#

documentation needs to present an example and add cross-references to/from WheelSource.validation_error.

#

Not sure about documentation though...

vestal delta
vestal delta
#

I just cut a release of installer. Lemme know if there's something needed/missing from it!

finite cradle
#

๐Ÿ‘€

calm pewter
#

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.

vestal delta
#

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.

calm pewter
#

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...

rugged lantern
#

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?

swift jewel
#

You could set PYTHONPATH to the installer wheel path and then use python -m installer to make installer install itself.

rugged lantern
#

Awesome, looks like that worked! I didn't realized you could put a wheel directly on the path (maybe just a pure python wheel?)

swift jewel
#

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.

rugged lantern
#

I guess that also means I don't actually need to install installer into my environment

patent geode
#

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)

rugged lantern
#

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

granite stag
#

I don't think so, but I think it could be added

rugged lantern
granite stag
#

yeah, that and probably some "for each do" operation

rugged lantern
rugged lantern
#

Any plans for a new release soon? I'd love to start using the multi-wheel feature.

granite stag
#

I think yes, we just have to figure out the launchers

rugged lantern
#

ah, windows

granite stag
#

yeah

last agate
#

Windows -.-

stark sigil
granite stag
#

we are syncing with distlib on that, but there was a change in what binaries they ship

rugged lantern
granite stag
#

maybe

lucid silo
#

windows Windows10

granite stag
#

yeah

#

at the same time, some complain ["why is windows support not a hard requirement"](#pip message)

karmic ridge
#

What's the issue with the launchers?

vestal delta
#

I've set up trusted publishing configuration on PyPI.

vestal delta
# karmic ridge What's the issue with the launchers?

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!).

sage dirge
#

Hi, may I ask to be a maintainer of installer? some changes need to be made to support Python 3.13
@vestal delta

granite stag
#

@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

sage dirge
forest hornet
granite stag
forest hornet
sage dirge
granite stag
karmic ridge
vestal delta
#

If vinay is open to moving this around, I am supportive of the idea!

granite stag
#

I am up to help as well

granite stag
#

@sonic yew wrong channel, #pypi

granite stag
#

@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

karmic pagoda
#

Uhhh, I'll try to get back to you in a few days, but frankly, I'm probably not the best person to ask.

granite stag
warped axle
#

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...

granite stag
glossy lotus
limber tiger
#

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!

granite stag
#

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".

limber tiger
#

awesome, thanks โ€“โ€“ appreciate it!

granite stag
gritty granite
granite stag
novel hearth
#

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?

gleaming reef
#

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)