[Distutils] How to handle launcher script importability?

[Jason R. Coombs]

> -----Original Message-----
> From: Steve Dower [mailto:Steve.Dower at microsoft.com]
> Sent: Monday, 12 August, 2013 15:03
>
> Jason R. Coombs wrote:
> > 6. Two to three files to do the job of one. In fact, the "job" isn't
> > much more than to invoke code elsewhere, so it seems ugly to require
> > as many as three files to do the job. Then multiply that by the
> > Python-specific version and you have up to six files for a single script.
>
> While I can understand this from the POV of the implementer/maintainer,
> I've never heard a single Windows user mention it. And with an embedded
> manifest, it's no more than one .py and one .exe-per-Python-version.

Thanks Steve (for this and other comments).

I do want to remind that silence is not consent. The multiple files per script 
has always bugged me (as a user, not implementer), but up until now, I've 
always considered it a necessary evil. And now that it's not necessary, it's 
just evil. Over the past day, I've realized/recalled even more problems 
stemming from side-by-side executables (some of which also apply to other 
non-executable side-by-side solutions such as markers and manifests):

1. Renames, deletes, and other actions must be synchronized. There's an 
implicit connection between the files, but it's implicit. And while it's 
relatively easy to imagine how one can manage the synchronicity, in practice, 
it's harder. For example, to delete a script, one has to be careful to delete 
{script_name}-script.py and {script_name}.exe. If one wants to rename, two 
renames have to occur. What would otherwise be a simple, intuitive operation 
now has a semantic and technical burden.
2. Discoverability is diminished. Imagine for example that you want to delete 
all scripts that reference a particular package (as one is wont to do when 
that package is removed). If there's any side-by-side content, it's not 
sufficient to grep the files and delete the matching files, but one must 
instead write a routine or otherwise resolve the matches to their side-by-side 
equivalents and perform the same operation on them.
3. A directory listing is distracting and unnecessarily twice as long, as 
there's two files per script. This necessarily means more scrolling and actual 
human time spent parsing and organizing that structure. And since there's not 
exactly two files per script (only those with a launcher), the pairing isn't 
consistent. With one file per script, the listing matches the essence of the 
directory's content.
4. Updates to the launcher won't apply to existing scripts. If the launcher is 
updated, the side-by-side versions will remain out-of-date until their scripts 
are re-installed. If the launcher is associated with the file type, then the 
state of the launcher can be managed independently of the scripts.
5. Files in use can't be replaced. Because a Windows executable that's in use 
is not allowed to be overwritten, it's not possible to use a script to update 
itself. For example, running 'easy_install -U setuptools' will result in an 
error because the easy_install.exe is in use.
6. There are potentially privilege issues and security aspects to the separate 
files that haven't yet been uncovered. On a multi-user system, there are 
considerations about ownership and permissions on the files. When there are 
multiple files per script, it's less obvious how permissions should be 
assigned. It's not obvious to me this poses a significant issue, but it sure 
seems easier to manage these issues on a single file rather than multiple.

All of these issues except for (6) have impacted my ability to work 
effectively with the side-by-side launchers currently on the system. It's one 
of the things I love about working on the Unix systems. Now that I feel like 
we're so close to a similarly-elegant solution on Windows, I want to see it 
employed (even if it's only opt-in, although I would prefer we work toward a 
solution that ultimately defaults to a single file mode for scripts).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6572 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130813/b144f11a/attachment-0001.bin>