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/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
