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

[M.-A. Lemburg]

Lindberg, Van wrote:
> 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.

I'm not sure I understand the point in making that change.

Could you expand on the advantage of using "bin" instead
of "Scripts" ?

Note that distutils just provides defaults for these installation
locations. All of them can be overridden using command line
arguments to the install command.

FWIW: I've dropped support for bdist_wininst in mxSetup.py
since bdist_msi provides much better system integration.

> 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.
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 21 2012)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2012-04-03: Python Meeting Duesseldorf                     13 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/