Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from PyPM's point of view]
On Sun, 19 Jul 2009 at 16:07, Nick Coghlan wrote: David Lyon wrote: So it isn't clear why you want to remove the thing that you are advocating works so great Jim was quoting someone *else* that had suggested removing it (I'm not sure how serious the original suggestion actually was though). It was Tarek, and I'm pretty sure it was in the nature of what rhetoricians (among others) call "reductio ad absurdum". But Tarek would have to let us know for sure, since it seems from subsequent discussion that the notion is not _completely_ absurd, just mostly :) --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
Sorry Dirkjan - I just noticed I didn't CC you on this mail originally. I'm wondering if you have any more thoughts on these EOL issues and if there is anything I can do to help? Cheers, Mark On 4/07/2009 2:03 PM, Mark Hammond wrote: On 4/07/2009 12:30 PM, Nick Coghlan wrote: ... I think there needs to be a solid answer in place for these use cases before the actual migration to Mercurial takes place. A hand-waving "use win32text" isn't enough - it needs to be "use win32text with these exact settings" (with server side hook support to enforce the rules). And since Mercurial doesn't even allow us to say "this is a binary file" the way CVS used to I'm currently not seeing any way for that to happen except for win32text to be updated to correctly handle wild cards in combination with negative filters. I agree with your conclusion. My ruminating on this over the last few months leaves me thinking this would involve: * my older 'accepted but then lost' hg patch to allow an explicit 'none' rule for a single file to override wildcards. * win32text be enhanced to use a normal versioned file in the root of the repo, much like hgingore, where a project can maintain project wide rules. * win32text be enhanced such that all python developers, regardless of platform, are willing to use this extension, even if the majority of files happen to use their native line ending (sauce for the goose is sauce for the gander, and all that...) * commit hooks be implemented to enforce this - but this should not be necessary if the above was implemented and socially enforced. Cheers, Mark Cheers, Nick. [1] http://mail.python.org/pipermail/python-dev/2006-March/062225.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from PyPM's point of view]
On Sun, Jul 19, 2009 at 3:08 PM, R. David Murray wrote: > On Sun, 19 Jul 2009 at 16:07, Nick Coghlan wrote: >> >> David Lyon wrote: >>> >>> So it isn't clear why you want to remove the thing that you are >>> advocating works so great >> >> Jim was quoting someone *else* that had suggested removing it (I'm not >> sure how serious the original suggestion actually was though). > > It was Tarek, and I'm pretty sure it was in the nature of what > rhetoricians (among others) call "reductio ad absurdum". But > Tarek would have to let us know for sure, since it seems from > subsequent discussion that the notion is not _completely_ absurd, > just mostly :) > Yes, well, maybe we should go back to Python-ideas to continue this discussion, :) What made me say that, is the unecessary complexity of the situation because we have right now : "Python the application" v.s. "Applications that uses Python the interpreter" So we have: A - a drop-it-in directory were we can put packages and modules B - installers that adds automatically packages and modules in the drop-it-in directory C - applications that uses these installers to install themselves and their dependencies in the drop-it-in directory. D - a tool like virtualenv that duplicates a Python installation so this drop-in-in directory is not shared globally C - installation documentation that tells you to use virtualenv to create a custom environment so you are sure not to break dependencies. (But you can break them nevertheless because using virtualenv is not enforced :) ) E - OS packagers that installs all distributions in the drop-it-in directory (or a similar place) So if you remove the global site-packages, "Python the application" dissapear in favor of "Python the interpreter", and people have to point a local, non-shared drop-it-in directory to run any python application that uses extra modules: 1- For Jim's case, the per-user site packages (PEP 370) can be used 2- For every application it can be a local directory loaded in sys.path at startup 3- For OS packagers a single directory where they maintain a collection of packages and modules for their system. But unfortunately, the problem remains because of (3) : OS packagers will fight against applications (2) that deal with their own dependencies to avoid having duplicate packages in their system. That's why a shared space, not loaded at startup by site.py, that knows how to handle multiple versions for the same distribution would be required. Every script (eg application) would decide which version to use, or use the default version by default. And a smart PEP 302 loader/importer would get the right versions. Regards Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove site-packages?!? [was: [D istutils] PEP 376 - from pythonpkgmgr's point of view]
On Sun, 19 Jul 2009 17:15:44 +0200, Tarek Ziadé wrote: > What made me say that, is the unecessary complexity of the situation > because we have right now : > > .. > > So if you remove the global site-packages, "Python the application" > dissapear in favor of "Python the interpreter", > and people have to point a local, non-shared drop-it-in directory to > run any python application that uses extra modules: > > 1- For Jim's case, the per-user site packages (PEP 370) can be used > 2- For every application it can be a local directory loaded in > sys.path at startup > 3- For OS packagers a single directory where they maintain a > collection of packages and modules for their system. > > But unfortunately, the problem remains because of (3) : OS packagers > will fight against applications (2) that deal with their own > dependencies to avoid having duplicate packages in their system. Well now I completely understand the jist of what you are saying.. And I completely agree with the direction of your comments. This problem is being solved within the pythonpkgmgr project. As we are allowing a distinction between operating system packages and developer packages. I only have ubuntu, and not OS-X at the moment, but let me explain with that. The operating system can install packages into /usr/lib/pythonX.X/ site-packages. The develeloper can install packages into /usr/local/pythonX.x/ site-packages. Therefore providing two seperate areas for packages to reside and eliminating the chance for serious conflict. The main problem imho has been that easy_install by default has installed to /usr/lib/pythonX.X/site-packages when in fact that really is an operating system controlled directory. So naughty naughty to setuptools That's why in pythonpkgmgr, we're moving to an entirely different place where there is no chance of conflict with the os package manager and python packages can be installed without su privelages. If the user wishes to install o/s packages that's fine and if they wish to install developer packages that's fine too. The saving grace here is the gui that remembers the appropriate command line switches that are needed to direct this behaviour because it doesn't happen by default in easy_install. Under ubuntu, it seems to be /usr/local/pythonX.X/site-packages and I am checking other posix operating systems and trying to work out what the equivilents might be. When I have it working.. I will let you know.. I'm just trying to work out how to get the permissions going correctly. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
