[Distutils] wheel without console_scripts in 0.20.0

[Daniel Holth]

On Sat, Jul 20, 2013 at 4:34 AM, Vinay Sajip <vinay_sajip at 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.