[Python-Dev] PEP 376 - Open questions

[Paul Moore]

2009/7/6 P.J. Eby <pje at telecommunity.com>:
> At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
>>
>> As promised, here are some open questions on PEP 376.
>>
>> - Will the public API names be changed from *egginfo* to *metadata*?
>
> +1 (FWIW, 'metadata' is what pkg_resources API refers to this kind of stuff
> as.)

Thanks. I think this one is pretty non-controversial.

>> - What precisely are the use cases for absolute path names? Concrete
>> examples are needed. With the current spec, some things can go wrong
>> (e.g., see below), so we need real use cases to know how to address
>> this.
>
> The purpose is to be able to remove scripts, data files, documentation, etc.
> that's stored in some place that's not package-relative, and survive a move
> of the package directory itself.
>
> For example, suppose I install with --prefix=~, and have files in ~/bin and
> ~/lib.  I then move ~/lib/python2.7 to ~/pylib.  If the scripts were
> installed with a relative path, this would break the link to the script
> still living in ~/bin.
>
> Now that I'm thinking about this, it occurs to me that there is another way
> to address this besides mixing relative and absolute paths in RECORD, and
> that is to make *all* the paths relative, and include an original
> installation location in INSTALLER.  Then, it would be possible to detect
> whether the installation location had been moved and handle it
> accordingly...  for some definition of "accordingly".
>
> I agree that further discussion is probably needed to resolve this.

I'm not 100% sure I follow your logic here. If you're renaming
directories after install, without involving the package manager, I
think you probably deserve whatever you get :-)

Having said that, your proposal (all paths relative, plus an install
location) is similar to something I mentioned earlier (but better
explained :-)) The only case it doesn't cater for is when an installed
file can't be expressed as relative to the "install location" (which
would involve being on a different drive on Windows). That's likely to
never work, so I doubt it counts in any case. I've got some concerns
about the possibility of having locations "above" the install location
- something like "../../scripts/driver.bat". I'm not sure if such
things will work (consider if the install location is a zipfile or
egg) but nor am I sure anything generates such names.

As you say, more discussion (and use cases!) would help here.

>> - How will bdist_wininst/bdist_msi/bdist_rpm be updated?
>
> bdist_wininst, bdist_dumb, and various others use 'install --root' pattern
> to generate files for installation, which means that they would
> transparently end up writing a correct RECORD file, except for the inclusion
> of incorrect absolute paths for non-libdir-relative files.  However, if we
> used the "all relative in RECORD, with a base in INSTALLER", these cases
> could transparently be treated as another instance of install directory
> relocation.
>
> I don't know if bdist_msi does a --root install before generating the .msi;
> if it does, then it should work the same way.

Yes, that sounds like a plausible approach.

>> - Can distutils be made to install files in places the current RECORD
>> file spec can't handle? (I think the answer is "yes"). What happens
>> then?
>
> Surely an absolute path is sufficient?

Current spec says relative or $PREFIX/... or $EXEC_PREFIX/...

I think that was based on earlier discussion, but it's hampered by the
fact that nobody's pointing at a real case of a distribution that
actually tries to *install* files in odd places. (Actually, something
that installs a driver script, like twisted's twistd or nose's
nosetests, would do - I'll see what I can find tomorrow).

>> - Should distribution names be case insensitive on case insensitive
>> filesystems? For comparison, module/package names are always case
>> sensitive even on case insensitive systems.
>
> IMO, they should be case-insensitive *regardless* of filesystem case, and I
> believe PyPI has already begun disallowing packages with only case-distinct
> names (e.g. 'Zope' vs. 'ZoPe') to be registered.

OK, that's another option :-) It's not hard to change the code, so as
long as a final decision is reached at some point, we're OK here...

Thanks for the comments,
Paul.