[Python-Dev] Python install layout and the PATH on win32

[Lindberg, Van]

Mark, MAL, Martin, Tarek,

Could you comment on this?

This is in the context of changing the name of the 'Scripts' directory 
on windows to 'bin'. Éric brings up the point (explained more below) 
that if we make this change, packages made/installed the new packaging 
infrastructure and those made/installed with bdist_winist and the old 
(frozen) distutils will be inconsistent.

The reason why is that the old distutils has a hard-coded dict in 
distutils.command.install that would point to the old locations. If we 
were to make this change in sysconfig.cfg, we would probably want to 
make a corresponding change in the INSTALL_SCHEMES dict in 
distutils.command.install.

More context:

On 3/20/2012 10:41 PM, Éric Araujo wrote:
> Le 20/03/2012 21:40, VanL a écrit :
>> On Tuesday, March 20, 2012 at 5:07 PM, Paul Moore wrote:
>>> It's worth remembering Éric's point - distutils is frozen and changes
>>> are in theory not allowed. This part of the proposal is not possible
>>> without an exception to that ruling. Personally, I don't see how
>>> making this change could be a problem, but I'm definitely not an
>>> expert.
>>>
>>> If distutils doesn't change, bdist_wininst installers built using
>>> distutils rather than packaging will do the wrong thing with regard to
>>> this change. End users won't be able to tell how an installer has been
>>> built.

Looking at the code in bdist_wininst, it loops over the keys in the 
INSTALL_SCHEMES dict to find the correct locations. If the hard-coded 
dict were changed, then the installer would 'just work' with the right 
location - and this matches my experience having made this sort of 
change. When I change the INSTALL_SCHEMES dict, things get installed 
according to the new scheme without difficulty using the standard tools. 
The only time when something is trouble is if it does its own install 
routine and hard-codes 'Scripts' as the name of the install directory - 
and I have only seen that in PyPM a couple versions ago.


>  From the top of my head the developers with the most experience about
> Windows deployment are Martin v. Löwis, Mark Hammond and Marc-André
> Lemburg (not sure about the Windows part for MAL, but he maintains a
> library that extends distutils and has been broken in the past).  I
> think their approval is required for this kind of huge change.

Note the above - this is why I would like your comment.


> The point of the distutils freeze (i.e. feature moratorium) is that we
> just can’t know what complicated things people are doing with
> undocumented internals, because distutils appeared unmaintained and
> under-documented for years and people had to work with and around it;
> since the start of the distutils2 project we can Just Say No™ to
> improvements and features in distutils.  “I don’t see what could
> possibly go wrong” is a classic line in both horror movies and distutils
> development<wink>.
>
> Renaming Scripts to bin on Windows would have effects on some tools we
> know and surely on many tools we don’t know.  We don’t want to see again
> people who use or extend distutils come with torches and pitchforks
> because internals were changed and we have to revert.  So in my opinion,
> to decide to go ahead with the change we need strong +1s from the
> developers I named above and an endorsement by Tarek, or if he can’t
> participate in the discussion, Guido.
>
> As a footnote, distutils is already broken in 3.3.  Now we give users or
> system administrators the possibility to edit the install schemes at
> will in sysconfig.cfg, but distutils hard-codes the old scheme.  I tend
> to think it should be fixed, to make the distutils-packaging
> transition/cohabitation possible.

Any comment?

Thanks,
Van

CIRCULAR 230 NOTICE: To ensure compliance with requirements imposed by 
U.S. Treasury Regulations, Haynes and Boone, LLP informs you that any 
U.S. tax advice contained in this communication (including any 
attachments) was not intended or written to be used, and cannot be 
used, for the purpose of (i) avoiding penalties under the Internal 
Revenue Code or (ii) promoting, marketing or recommending to another 
party any transaction or matter addressed herein.

CONFIDENTIALITY NOTICE: This electronic mail transmission is confidential, 
may be privileged and should be read or retained only by the intended 
recipient. If you have received this transmission in error, please 
immediately notify the sender and delete it from your system.