On Mar 23, 2012 10:21 PM, "PJ Eby" <p...@telecommunity.com> wrote: > > > On Mar 23, 2012 4:19 PM, "VanL" <van.lindb...@gmail.com> wrote: > > > > Three notes. FIrst, distutils.cfg doesn't always work because it is centered around the idea of set paths that are the same each time - which doesn't always work with virtualenvs. > > And the virtualenv doesn't contain its own copy of distutils.cfg?
It can, but a new one. Virtualenvs don't carry over the distutils.cfg from the main installation. Thus, using distutils.cfg in the virtualenv would require editing the .cfg for every new virtualenv-and it still wouldn't work all the time for the other reasons discussed. > > Second, most installer tools don't follow distutils.cfg. Even if that helps for python setup.py install, the other tools are still broken when you want to specify a layout. > > So, we should change Python to fix the broken tools that don't follow documented standards for configuring installation locations? If the documented functions don't work for the use cases, there is nothing else. Again, see the comments in PyPM. > > If the tools are that broken, aren't they going to break even *harder* when you change the paths for Windows? If people substitute on hard-coded value for another, does cross platform consistency help? And ifthat focuses attention on the new packaging APIs and the correct way to do it, isn't that even better? > > And fourth, (because nobody expects the spanish inquisition), isn't the gratuitous difference a (small but) obvious wart? > > It's hardly the only wart we keep around for backwards compatibility. If it's going to change, it needs a proper transition period at the least. Already proposed, making a transition over three releases with it starting as an off by default option in 3.3.
_______________________________________________ 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
