wheel without console_scripts in 0.20.0
Hi Paul. https://bitbucket.org/dholth/wheel/commits/db913ecc2c0bb7fec14ba9eae68f99d9a... Wheel 0.20.0 won't put entry_points console_scripts and gui_scripts in the wheel itself. The new "python -m wheel install-scripts wheel pip" command for example would install those scripts for wheel and pip into the default scripts directory. It requires setuptools, not just pkg_resources. Here's what I did to accomplish that using easy_install: dist = 'pip' pkg_resources_dist = pkg_resources.get_distribution(dist) install = wheel.paths.get_install_command(dist) command = easy_install.easy_install(install.distribution) command.args = ['wheel'] # dummy argument command.finalize_options() command.install_egg_scripts(pkg_resources_dist) It would be fun to experiment with alternative implementations like the "just import and run it" wrapper, and it might be nice to update the RECORD of installed files as part of the operation. It should also be possible to use less easy_install.
On 20 July 2013 00:14, Daniel Holth <dholth@gmail.com> wrote:
it might be nice to update the RECORD of installed files as part of the operation.
I would argue that keeping RECORD up to date is essential, as not doing so breaks uninstall. It would also not be in line with PEP 376 It's actually not entirely clear that PEP 376 allows for a second tool to update an installation like this anyway (what goes into the INSTALLER file in that case?) Actually, a more general question - to what extent is PEP 376 still relevant in the light of Metadata 2.0? Something needs to be updated to ensure that the format and management of the RECORD file remains standardised. There is a reasonable amount of information that is *only* specified in PEP 376, so it's not really possible just to deprecate it wholesale... Paul.
On 20 July 2013 17:34, Paul Moore <p.f.moore@gmail.com> wrote:
On 20 July 2013 00:14, Daniel Holth <dholth@gmail.com> wrote:
it might be nice to update the RECORD of installed files as part of the operation.
I would argue that keeping RECORD up to date is essential, as not doing so breaks uninstall. It would also not be in line with PEP 376 It's actually not entirely clear that PEP 376 allows for a second tool to update an installation like this anyway (what goes into the INSTALLER file in that case?)
Perhaps define a solution along the lines of an UPDATES subdirectory with date/time based file names to avoid conflicts? For example: 1. Create a tracking directory as UPDATES/YYYYMMDD_hhmmss 2. Write an INSTALLER file to the tracking directory 3. Copy RECORD to RECORD.prev in the tracking directory 4. Update the main RECORD file with any changes I don't think that's necessary though. INSTALLER is supposed to be about tracking *ownership*, and registering a few extra files in RECORD doesn't change which installer is ultimately responsible for that distribution being present on the system. (Does pip actually do the INSTALLER consistency check to try to avoid getting into arguments with system package management tools?)
Actually, a more general question - to what extent is PEP 376 still relevant in the light of Metadata 2.0? Something needs to be updated to ensure that the format and management of the RECORD file remains standardised. There is a reasonable amount of information that is *only* specified in PEP 376, so it's not really possible just to deprecate it wholesale...
I don't expect any significant changes to the installation database format for metadata 2.0, except to deprecate METADATA in favour of something like "the contents of the distribution's .dist-info directory, including pydist.json as defined in PEP 426 (or later versions of the metadata standard)". In particular, I don't see any reason for RECORD to change as CSV is a good format for that data. If wheel and/or pip adopt a modification tracking system like the one I suggest above, then the updated PEP would standardise that, too (I think such a scheme would be overkill, though). We *might* introduce an optional SQLite based caching mechanism somewhere along the line, but I think that's more appropriately handled on the consumer side of things than it is on the installer side. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Paul Moore <p.f.moore <at> gmail.com> writes:
I would argue that keeping RECORD up to date is essential, as not doing so breaks uninstall. It would also not be in line with PEP 376 It's actually not entirely clear that PEP 376 allows for a second tool to update an installation like this anyway (what goes into the INSTALLER file in that case?)
I don't know if Daniel's post was replying to some other post that I've missed, so I'm not sure if Daniel is just trying things out or advancing his implementation more seriously. I think whatever does the installation (creates the .dist-info file) should be the INSTALLER. I don't know if it's a good idea for tools to subsequently change the contents of a .dist-info - do we have well established use cases for this? Unless I've misunderstood something, it's better for pip/wheel integration to be closer so that the .dist-info RECORD file is written in a single step. In distlib, that's done by Wheel.install, which is why I'm changing its API to accommodate the script generation requirements which have emerged.
Actually, a more general question - to what extent is PEP 376 still relevant in the light of Metadata 2.0? Something needs to be updated to ensure that the format and management of the RECORD file remains standardised. There is a reasonable amount of information that is *only* specified in PEP 376, so it's not really possible just to deprecate it wholesale...
PEP 376 and Metadata 2.0 are orthogonal to each other, in my view. The new metadata format simply replaces the key-value METADATA file with pydist.json and siblings(for commands, exports etc.) Regards, Vinay Sajip
On Sat, Jul 20, 2013 at 4:34 AM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
Paul Moore <p.f.moore <at> gmail.com> writes:
I would argue that keeping RECORD up to date is essential, as not doing so breaks uninstall. It would also not be in line with PEP 376 It's actually not entirely clear that PEP 376 allows for a second tool to update an installation like this anyway (what goes into the INSTALLER file in that case?)
I don't know if Daniel's post was replying to some other post that I've missed, so I'm not sure if Daniel is just trying things out or advancing his implementation more seriously. I think whatever does the installation (creates the .dist-info file) should be the INSTALLER. I don't know if it's a good idea for tools to subsequently change the contents of a .dist-info - do we have well established use cases for this? Unless I've misunderstood something, it's better for pip/wheel integration to be closer so that the .dist-info RECORD file is written in a single step. In distlib, that's done by Wheel.install, which is why I'm changing its API to accommodate the script generation requirements which have emerged.
I was a little surprised easy_install didn't already have a "redo the console scripts" command. Eggs omit the console scripts and put the normal scripts in .egg-info/scripts/. If the egg is installed instead of simply added to sys.path and used then easy_install iterates over the console_scripts and gui_scripts and writes them out. Obviously this operation should happen at or near the same time as the install but it will be quite harmless to append a few lines to RECORD. Shouldn't be any worse than the #! rewriting that already happens. I've decided to delay this version of wheel until I can come up with a patch to pip. And if you're in a hurry and deploying a web backend, why bother to generate the scripts at all? (not the default)
Actually, a more general question - to what extent is PEP 376 still relevant in the light of Metadata 2.0? Something needs to be updated to ensure that the format and management of the RECORD file remains standardised. There is a reasonable amount of information that is *only* specified in PEP 376, so it's not really possible just to deprecate it wholesale...
PEP 376 and Metadata 2.0 are orthogonal to each other, in my view. The new metadata format simply replaces the key-value METADATA file with pydist.json and siblings(for commands, exports etc.)
It's been a useful way to structure things.
participants (4)
-
Daniel Holth -
Nick Coghlan -
Paul Moore -
Vinay Sajip