Creating a package to _just_ install a wheel

The embedded signature feature was not developed very far. I think you could do some cool things in there, like automatically attaching timestamps to prove that a wheel was at least n days old, or expecting only that a particular key, identified by its fingerprint, signed any one of the wheels you might download instead of expecting that the entire wheel has a particular hash. Or simply being able to verify the wheel without caring about the compression algorithm used in the outer zip. But the feature did not get very far.

e.g. suppose you arranged for all the files in a release to be signed by a private key that is only used for a single release. Pass the fingerprint (cryptographic hash) of the public key to the installer. The installer would be able to check that you had any of the alternative files for that release, instead of just a single fileā€™s sha sum.

I had started doing that 3 years ago with GitHub - xavfernandez/cric so color me interested :smiling_face:

The issue I remember having was depending on distlib for the windows console scripts/launchers.

I wonder if itā€™s possible to extend/build on the Python Launcher code. What the launcher does feels similar to the venv redirector :thinking:

Create a repository, agree on initial scope, and figure out the API?

Sure!

Iā€™ve taken the liberty of creating GitHub - pradyunsg/installer: A fork for making that other thing better. and populating it with an initial scaffolding for a flit-based Python package. Iā€™ve also filed https://github.com/pradyunsg/installer/issues/1 for discussing the scope. Let me know in that issue if you want push access. :stuck_out_tongue:

If it is then should the repo be created in the PyPA org on GitHub based on who all is volunteering to help out?

IMO we can move the project to Python Packaging Authority Ā· GitHub once itā€™s actually a thing that works; if you disagree, letā€™s talk about that here. :slight_smile:

There are basically two launchers in common use. The py launcher doesnā€™t support appended zips (by default - thereā€™s conditional code in there that can be enabled). The distlib launchers are available as a separate project, https://bitbucket.org/vinay.sajip/simple_launcher. Those launchers are the ones that distlib uses, and could easily be re-used by another project (binaries are available, so you donā€™t need to compile your own copy). Thereā€™s no need to use distlibā€™s code, all that does is wrap the process of creating a zip and appending it to the launcher.

IMO, it would be nice if the simple_launcher launchers were more easily reusable (with ā€œproperā€ releases, for example), but thatā€™s just a minor point.

2 Likes

Hey all, I am super happy to help out as well.

My contribution level will be limited until I ramp up on what is being discussed in some cases (py.exe launcher doesnā€™t support appended zipsā€¦ I know what some of those words mean.) but I am willing to make up for it with enthusiasm and willingness to experiment.

Iā€™m reading through this thread this week and attempting to catch up on everything said (in particular PEP 427 called out by @uranusjr and the steps outlined by @dholth). If there is something I can start chatting with folks about designing Iā€™m happy to dive in.

As a newb, I am happy to do any boilerplate/busywork to get the idea up and running.

2 Likes