Re: [Python-Dev] .pth files are evil
On Sun, 10 May 2009 09:41:33 -0600, Zooko Wilcox-O'Hearn wrote: >> (Of course, this ignores the issue of uninstalling previous >> versions, or overwriting of conflicting files in the target -- does >> pip handle these?) > > GNU stow does handle these issues. I'm not sure GNU stow will handle the .PTH when deinstalling packages. In easy_install.PTH there will be a list of all the packages installed. This list really needs to be edited once a package is removed. The .PTH files are a really good part of python. Definitely nothing evil about them. David ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
On Fri, 10 Jul 2009 05:53:13 +1000, Nick Coghlan wrote: > There are probably all sorts of other useful distinctions which could be > made. However, that would be a topic for a different PEP - as Tarek > pointed out, improving distutils is such a huge can of worms that trying > to tackle all the issues in a single PEP would most likely just result > in developer burnout rather than improvement. All it requires is a few word changes to the documentation to tell programmers to put your documentation in "docs"... If that is going to burn out the existing developers, it might suggest that it is time to get some fresh developers onboard Thats not even a programmatic fix... Regards David ___ 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
Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files
On Thu, 09 Jul 2009 16:00:41 -0400, Fred Drake wrote: > At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote: >> - - docs >> - - i18n / locales > > > On Jul 9, 2009, at 3:09 PM, P.J. Eby wrote: >> Unfortunately, the distutils don't currently have a way to specify >> these. > > > There actually is a way to identify documentation files via setup.cfg, > but I don't know if the RPM packagers (or others) use that information. Hi, Perphaps the RPM packagers dont use it but the Python Package Manager GUI (http://sourceforge.net/projects/pythonpkgmgr) does. With that, if there is any package documentation in a docs directory the user can click on it and display it. Regards David ___ 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
[Python-Dev] PEP 376 - from pythonpkgmgr point of view
On Wed, 15 Jul 2009 13:47:35 -0400, Chris McDonough wrote: > I've been trying to follow this discussion now for weeks. The signal to > noise ratio is pretty low. I'm -1 on that.. As a relative newcomer to python packaging I'm finding all these discussions very informative. :-) > I'd love to have an stdlib solution for distribution packaging and > installation. That's right. I'd love to find out what the process is for submitting my pythonpkgmgr project for consideration into the stdlib. As it fills a huge gap that you've just identified that currently exists within the python that is being shipped today. That is, allowing users to easily install packages from pypi. > But I think we might as well pack it up and go home if the folks whom are > contributing to the discussion "recreationally" (whom are not themselves > implementers and potential implementers or spec writers or potential spec > writers of packaging systems) continue to chime in on *every single issue*, > > contributing only stop energy. It's just completely pointless. We can all work in different ways.. I'm not writing PEPS and don't care too much about how the internals of a package work. As long as there are APIs for such stuff I'm happy. What I'm working on is to try to improve the user experience which isn't so handled so easily by a design by commitee process. Packaging and Distutils, need to be looked at wholistically as well. It's not just about the api's, but how well they work. It's not noise it's just the process ps: (http://peak.telecommunity.com/DevCenter/EasyInstall) "Easy Install ... Please share your experiences with us! If you encounter difficulty installing a package, please contact us via the distutils mailing list. (Note: please DO NOT send private email directly to the author of setuptools; it will be discarded. " So what are we to do if we find issues with setuptools other than to post to distutils? David ___ 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
Re: [Python-Dev] Remove site-packages?!? [was: [D istutils] PEP 376 - from PyPM's point of view]
On Sat, 18 Jul 2009 16:07:39 -0400, Jim Jewett wrote: > What about those people *without* versioning issues? > > I have no qualms suggesting that package management programs avoid the > use of site-packages. Such programs do need to cater to edge cases. I'm just wondering how that is possible? Given that a package management system (pythonpkgmgr - for example) is a tool to assist in the management of packages in site-packages. If you take away the drop in directory (site-packages), effectively you're taking away the place for system drop in packages. I can't see the point in that. > But a single drop-it-in directory works great for the vast majority of > *my* needs; requiring me to drink the Kool-Aid from a specific package > management system just to get access to any add-ons -- even those I > wrote myself in pure python -- would be a huge step backwards. Where you keep your packages is entirely up to you. Even with the Python Package Manager, you can still have unversioned packages in project directories. That doesn't change. And you can still have unversioned packages in site-packages. So I can't really see that having a Package Manager program takes your use case scenerio backwards because it wouldn't really change it. (repeating) > But a single drop-it-in directory works great for the vast majority of > *my* needs; That's exactly what site-packages is. So it isn't clear why you want to remove the thing that you are advocating works so great David ___ 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
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 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
Re: [Python-Dev] Remove site-packages?!? [was: [D istutils] PEP 376 - from pythonpkgmgr's point of view]
On Tue, 21 Jul 2009 13:41:41 -0400, Tres Seaver wrote: >>> 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 behvior isn't setuptools' fault: it is the behavior of *any* > distutils-derived app. "OS controlled directory" is not a concept which > the distutils honors at all: $prefix/lib/pytoonX.Y/site-packages is the > *intended* installation location for any modules not shipped with Python. Ok - so naughty distutils... > Consider the case where the user has built a separate python (e.g., to > avoid conflicting with the OS version) in /opt/PythonX.y: are you > actually saying that distutils / setuptools should somehow know the > difference betweeen /usr/lib/pythonX.y/site-packages and > /opt/PythonX.Y/lib/pythonX.Y/site-packages? It already does. If you run the python in /opt/pythonX.X you'll get a different value for sys.path than when you run the other python from /usr/lib/pythonX.X. Try it and see for yourself.. That's because sys.path is calculated relatively within site.py depending on where the interpretor is run from. > Or are you asserting that > it is somehow invalid for distutils / setuptools to install things into > /opt/PythonX.Y/lib/pythonX.y/site-packages, which is certainly not an > "OS controlled directory." Not at all. All I'm saying is that after so many years of python under linux and operating system we should have observed the common use cases and learned a thing or two. If you hadn't noticed, there is mayhem in package installation because the operating system tries to install its packages in the same place as setuptools does in development mode. That has got to be asking for trouble.. When I go into python on ubuntu I see there is /usr/local/pythonX.X/lib/ site-packages and I'm wondering why the hubba setuptools/distutils doesn't put packages there by default. That would solve a lot of problems. Just leave /usr/lib/pythonX.X//lib/site-packages to the O/S. Wrapping up.. most of the functionality that I'm asking for is already there. So I don't require anything extra. I don't want things taken out. All I'm suggesting is that we use what we already have a bit smarter. David ___ 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
Re: [Python-Dev] Remove site-packages?!? [was: [D istutils] PEP 376 - from pythonpkgmgr's point of view]
On Tue, 21 Jul 2009 21:46:11 -0400, James Y Knight wrote: > Uh guys, I'm not sure if anyone here noticed, but Debian and Ubuntu > have switched to install their distribution-supplied python libraries > into: > /usr/lib/pythonX.Y/lib/dist-packages > and distutils by default will install into > /usr/local/lib/pythonX.Y/dist-packages > > starting with python 2.6. > .. > Since that email says "Discussed this with Barry Warsaw and Martin v. > Loewis", I'd assume this change would be more widely known in the > distutils/python-dev community, but apparently not?? Forgive my ignorance... I'm working with 2.5 on ubuntu and didn't think to try 2.6... It's good to know that the problem is fixed in 2.6 but I still need to make things work for pythonpkgmgr on ubuntu py2.5 as 2.5 is the default for ubuntu 8.10. Take care David ___ 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
Re: [Python-Dev] Remove site-packages?!? [was: [D istutils] PEP 376 - from pythonpkgmgr's point of view]
On Wed, 22 Jul 2009 10:26:59 -0400, Tres Seaver wrote: > You were complaining that setuptools / > distutils wants to put files in an "OS-controlled directory": I complain about many things - so what. > I was > asking how Python was supposed to know the difference between > /usr/lib/python2.x/site-packages (presumably "OS-controlled") and > /opt/Python2.x/lib/python2.x/site-packages (definitely not > "OS-controlled"). Well, at an interpreter level it doesn't, and I don't expect it to. > The solution is to avoid doing distutils / setuptools operations as > root, *ever*, and instead use either an alternate install location (such > as /opt/Python2.x) Have you tried this ? When I try to run it without su privelages setuptools crashes... (ubuntu 8.10) Running installer ... /usr/bin/easy_install "/media/Elements/Pythn Packages/html5lib-0.10.zip" ERRORS: Traceback (most recent call last): File "/usr/bin/easy_install", line 5, in from pkg_resources import load_entry_point ImportError: No module named pkg_resources Error in sys.excepthook: Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/apport_python_hook.py", line 78, in apport_excepthook report_file = open(pr_filename, 'wt') IOError: [Errno 13] Permission denied: '/var/crash/_usr_bin_easy_install.1000.crash' Original exception was: Traceback (most recent call last): File "/usr/bin/easy_install", line 5, in from pkg_resources import load_entry_point ImportError: No module named pkg_resources I can only get it to work with sudo. > That is precisely how I think of virtualenv: it sits on top of distutils > / setuptools, and makes it sane to do Python development without > compromising the core system. For me I prefer using a tool with a GUI interface. Take care David ___ 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
Re: [Python-Dev] Remove site-packages?!? [was: [D istutils] PEP 376 - from pythonpkgmgr's point of view]
On Wed, 22 Jul 2009 23:22:56 +0200, "M.-A. Lemburg" wrote: > Maybe I've misunderstood some important detail, but how will > their "change" help with anything other than making their > distribution a non-standard Python installation ? The Debian/ubuntu distribution isn't non-standard. If anything I'd prefer to suggest that it is in many ways "a standard" Here's a sys.pth from a mac... ['', '/Library/Frameworks/Python.framework/Versions/2.6/lib/python26.zip', '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6', '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-darwin', '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac', '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-scriptpackages', '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk', '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-old', '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload', '/Users/david/.local/lib/python2.6/site-packages', '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages'] You can see that there are many choices along sys.path for installing packages. > distutils allows for a great deal of flexibility. For some > reason, this does not appear to be known to a larger > audience. People forget command lines - that's why. > I can only recommend reading Greg's great write-up about the > end-user perspective of installing Python modules: > > http://docs.python.org/install/ It's good documentation of course. Cheers to Greg but the old method is so tedious. That really is the hard way. pythonpkgmgr offers a much easier solution by wrapping easy_install and/or pip. You just type in parts of the package name into a search box, click [search], a search of pypi is done, click [install] and your package is downloaded and installed. It's a much more modern way of doing package installation and requires absolutely no typing on a command line. > A little known fact is that distutils can easily be customized > using config files: > > http://docs.python.org/install/#distutils-configuration-files Perphaps. But it seems only for advanced users.. and I couldn't figure out on the face of it what advantage it would have. Take care David ___ 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
[Python-Dev] Update to Python Documentation Website Request
Hi Greg, I'm on the python-dev mailing list and somebody gave me a link to a page that you have done: http://docs.python.org/install/ Can I ask that you also provide a link for windows users to my project: http://sourceforge.net/projects/pythonpkgmgr/ Our project provides an alternative to command line installation. And can save a lot of time for users when they wish to install packages. Thanks David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
> That's a document describing how to use âdistutilsâ, which is what > every > recipient of Python will already have installed. > >> Can I ask that you also provide a link for windows users >> to my project: >> >> http://sourceforge.net/projects/pythonpkgmgr/ > > That doesn't seem at all appropriate; promoting third-party packages > isn't at all what the above document should be doing. Distutils was once seperate and was then included in the standard python. So i guess that I am working with the same goal in mind. > If people want an alternative to the standard tools provided in Python, The Python Package Index http://pypi.python.org/> is the > right place to be promoting (free-software) third-party tools. Well I can sure try that and thank you for the tip. Btw, at the moment there exists no inbuilt mechanism within python for retrieving packages from pypi. Imho this is an omission for a so called 'batteries included' language. Distutils is a builtin module for 'pushing' a developer package 'to' pypi. But there is no corresponging mechanise for a user to 'pull' packages back. Surely this is a gap in the standard distro? So it is not inappropriate for me to ask about this on this list. Take care David ___ 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
Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from pythonpkgmgr's point of view]
Hi Floris, That's exactly how I see it and i totally agree. My contribution is to make a Package Manager Gui that tries to be supportive of what you describe so well. If i have any complaint about the state of affairs it would only be that it takes a newcomer such a long time (months) to fully understand what should be a 5 minute thing as you so well describe below. > On Wed, Jul 22, 2009 at 07:08:26PM -0400, Glenn Maynard wrote: >> On Wed, Jul 22, 2009 at 5:22 PM, M.-A. Lemburg wrote: >> > Maybe I've misunderstood some important detail, but how will >> > their "change" help with anything other than making their >> > distribution a non-standard Python installation ? >> >> I think I'm a little confused, too, because Python supports the >> /usr|/usr/local separation just fine (setup.py install >> --prefix=/usr/local). >> >> It seems like it's also using "dist-packages" instead of >> "site-packages". That part, I don't understand at all--distribution >> packages should go in /usr/lib/pythonx.y/site-packages, and "site" >> packages go in /usr/local/pythonx.y/site-packages; /usr/local *itself* >> means "non-distribution site-installed stuff". If that's what you're >> referring to, then at least on first impression I agree. > > The way Debian does this isn't that stupid. It solves the problem of > the sysadmin intalling Python distibutions for the system Python > without writing in the system locations, which is a very reasonable > thing to do. > > Before Debian used dist-packages, > /usr/local/lib/pythonX.Y/site-packages was added to the sys.path of > the system Python and this was the location where a sysadmin should > add packages (although distutils did not default to that location, so > it wasn so it was still easy to mess up the system package > management). But this caused trouble for people who installed their > own Python in /usr/local since now you have the same > /usr/local/lib/pythonX.Y/site-packages shared by 2 interpreters. > > To solve this the system python moved to dist-packages instead, this > allows the local admin location to use > /usr/local/lib/pythonX.Y/dist-packages which does not conflict with > locally installed interpreters. Together with this they changed > distutils to install to /usr/local/lib/pythonX.Y/dist-packages by > default, so that a sysadmin would have to go out of their way to mess > up the system package management. > > This is a pretty neat solution to the problem. But the weird thing > (IMHO) is that distutils-sig completely refuses to see this > requirement. Generally it seems accepted that installing modules in > the system location (/usr/) is a bad thing, but last time it got > discussed there was a point blank refusal to accept that the local > admin needs a location in to install packages in. I think it would be > great if Python instead provided a general guideline or best practice > for this situation which would be explained in the documentation. > > > Regards > Floris > > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > ___ > 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/david.lyon%40preisshare.net > ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
> Raising it without at least glancing at the list archives which hold > copious amounts of virtual text on that topic is somewhat inappropriate > though :) Well I have consulted every available expert on the distutils list to the point where I feel 'up' with the issues at hand. They're great people.. And as helpful as they possibly can be.. But surely Python isn't only about archives and age old problems. Sure they might be there.. So lets get in and fix them.. Which is totally what i'm attempting to do at the moment even if packaging isnt perceived as being the most interesting part of python develepment going on today. Inapropriate or not, i want to donate my time to it.. Because i think we need 'fresh' thinking - not archive regurgitation. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Thu, 23 Jul 2009 18:30:58 +1000, Ben Finney wrote: > In which case you should work to get it accepted into standard Python > *before* asking for it to be promoted in the standard Python > documentation. I'm very interested in how I would go about doing that. Die-hard users probably know all the python issues relating to package installation and appear to have thick skins. An "easy-way" might not mean to much to them because they've settled down into their own comfort zone. But new users, who's first operating system comes complete with a polished GUI, have an expectation for having a polished GUI tool to download their python packages in. Under Windows, we get IDLE. And ActiveState as I understand are working on their own package manager for their own python distribution. So maybe it is appropriate to consider having a GUI Package Manager within at least the Windows distribution of Python. Yes, please tell me the process... I'm very interested. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes wrote: > I'm sorry to inform you that a wxWindows based solution has zero change > to get into the Python standard library ever. We are not going to add > another GUI toolkit to the core distribution. In executable form, the Package Manager does not require wxWidgets to be installed. There is no dependency for this to be installed. I'm not requesting that wxPython be added to the standard python distribution. > We might even remove TK > from the core and ship it as a separate package like bsddb3. That doesn't affect the Python Package Manager in any way. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Fri, 24 Jul 2009 17:54:09 +0200, Georg Brandl wrote: > David Lyon schrieb: >> In executable form, the Package Manager does not require wxWidgets >> to be installed. >> >> There is no dependency for this to be installed. > > What does "in exectuable form" mean? Compiled with py2exe. An executable ".exe" file is created under windows. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Fri, 24 Jul 2009 17:08:32 +0100, Paul Moore wrote: > I read this as meaning that David was proposing to ship a built > application (on Windows, bundled up with something like py2exe, I > guess) and any supporting DLLs such as the wxWindows ones would be > bundled in, but the wxPython package would *not* be shipped as part of > the standard library. That's correct. > In my view, for an "application" to be shipped with Python, whether it > be Idle, or a package manager, or pydoc, or whatever, it must: > - be written as a Python script > - depend only on packages shipped with the standard library This is true for the Package Manager in executable form. > Given that David's package manager uses setuptools to do the installs > (and now it appears it uses wxPython for its GUI) that immediately > disqualifies it for inclusion in my view - regardless of its value as > a package. Yes, It offers the choice to install via setuptools. As well as PIP. And it will be extended to Enstaller. Presently it used pkg_resources to read the list of packages installed which is part of setuptools. I was told it was the "right" and only way to read a list of packages. If using this package presents a problem, then it can be removed and I will replace the functionality with my own code. If the gui needs to be rewritten in TK this can be accomplished. I'm in no way pushing any GUI toolkit, and this was the one suggested to me by many. Redoing to meet the above criteria is achievable. If there's any other objections, can they be raised now before I start a rewrite? Thank you. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Fri, 24 Jul 2009 03:23:57 +0200, Christian Heimes wrote: > I'm sorry to inform you that a wxWindows based solution has zero change > to get into the Python standard library ever. Is that a personal preference or is there a software engineering reason for this? I wasn't suggesting including it in the standard library as I like others know how troublesome it can be. > We are not going to add > another GUI toolkit to the core distribution. We might even remove TK > from the core and ship it as a separate package like bsddb3. So is this a bias against native window applications? Does the application need to be web based? or console based? or TK based... ? For it to be acceptable.. Thank you David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 10:40:52 +1000, Ben Finney wrote: > I interpret this as expressing your intent to (eventually) have your > application included in standard Python. It's my intention to get a Package Manager included in standard python - yes. >> I wasn't suggesting including it in the standard library as I like >> others know how troublesome it can be. > > This appears to contradict what you said above. Not at all. In source form the pythonpkgmgr requires wx package. In executable form it does not. > No, it's a bias against adding things to Python that depend on things > not already in Python. That implies that nothing new can be added then. > Are you, or are you not, intending for your application to be in > standard Python? > > If that is your intent, I think Christian's answer is valid: > applications, especially ones that depend on third-party widget > libraries, shouldn't get added to Python. > > If that is not your intent, then your application shouldn't be mentioned > in standard Python documentation. The Python Package Manager can be written to work in console mode. It can be redone to work with the TK that already ships. That doesn't present any great problem. If it was the interests of python users that were foremost, being able to install packages in a modern way - Then I think there would be more room to move than this. It's no different than any other windows application that ships with dll files. I fully appreciate that changes could be necessary and I'm prepared to accomodate them. Not much more I can do than that.. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 11:25:27 +1000, Ben Finney > You omit the important part: adding a new thing to Python *so long as it > doesn't depend on anything outside Python*. I'm signing out on this silly discussion for now Any python program is dependant on things "outside" python. For example an operating system.. a computer... and a user perhaps for without such it wouldn't be possible to generate the all important 1Di0t errors that we so often have to deal with. >> The Python Package Manager can be written to work in console mode. > > I think this would be best. Haha - I'm glad somebody took this seriously... It was a sort of a joke comment but it's a serious possibility. > The functionality you often discuss around > this tool would be best implemented independently of any UI. It is anyway. That's why doing an entirely different UI isn't any major issue. I have a class and a possible command line interface behind the scenes. > It would, in fact, be best to work with the team performing ongoing > active standardisation of distutils functionality. I am already doing that. But there is a bias against windows development and a bias against native applications. That's fine because I know they are using python on different platforms. I'm working on a proposal to make setup.py object oriented and "modern". http://wiki.python.org/moin/Distutils/Proposals So I'm doing as much as I can - really. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 16:00:13 +1000, Ben Finney wrote: > I think you know quite well what “depend on” means in this instance, > so this is taking it to silly extremes. haha - yes - no offence. It was just bad humour. Have a nice weekend David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 10:28:51 +0100, Paul Moore wrote: > ??? I see no bias as you describe in the distutils enhancement work. ok > Native applications are by definition not platform neutral. How does > your proposal help Linux users? Mac OS? Solaris? I'm doing a Linux/Solaris version. But I find issues every day that must be addressed. > If your concern is to make things easier for Windows users, then your > application is worthwhile, but it should probably remain an external > project. If it gets overwhelming support, maybe providing a > standardised version with a simplified UI in the core would be an > option. That sounds ok. > How many users do you have currently? Approx 250 downloads this (first) month for the windows version. I need to extend coverage to Linux and the Mac. Given that I'm relatively new to all this there's a learning curve. But so far so good. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 12:47:21 -0400, Terry Reedy wrote: The Python Package Manager can be written to work in console mode. >>> I think this would be best. >> >> Haha - I'm glad somebody took this seriously... It was a sort of a joke >> comment but it's a serious possibility. > > I took it seriously too ;-). It seems to me that you project can have at > least 3 components. It's logical and plausible. > 1) the core library module, which might or might not be targeted at eventual stdlib inclusion. I'm sure they'll fix distutils someday, and if they do, then I'll use that. > 2) a small console driver script. 3) one or more GUI scripts. It's possible. I'll give it serious consideration. > A TK version would be good from my > viewpoint as it does not require download and installation of any other > binaries. Sure. Who cares if it's not as slick as something else. I'll try when I have time. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sat, 25 Jul 2009 11:42:13 +0200, "Martin v. Löwis" wrote: >> It's my intention to get a Package Manager included in standard >> python - yes. > > In addition to the other constraints you'll have to meet for this > to happen, you also have to wait a rather long time (several years) > before inclusion becomes possible. This time is necessary for the > community to accept your tool, and evaluate it. Ideally, the request > for inclusion should not come from you, but from your users. Yes. But users have been asking for a tool and complaining loudly about the lack of such a tool. I know you're an extremely competent and those emails you perphaps floss over. But the pleas are many and when we compare python to other languages, python rates towards at the low end of the spectrum its third party-package management facilities. You can't seriously expect users to wait for years for an integrated package management tool. Especially on Windows - that's cruel :-) To date, there just hasn't been any movement on the building of such a tool due to whatever reasons. A Package Manager isn't a frivolous "nice-to-have" tool. It's essential for a new user. (if you want I can sift the last twelve months worth of ML archives and report on how many times easier package management has been asked for. And how difficult people are finding it) > No. It implies that any addition could only depend on Python (and > OS API) - so things *can* be added. For example, setuptools could > be added by this principle. OTOH, if your tool depends on setuptools, > you'll have to wait for setuptools to get included before inclusion > of your tool can be considered. Let's get precise. It doesn't "depend" on setuptools. But it will install setuptools if the user requests to use setuptools/easy_install. So we should only be back to the lack of a TK interface and the fact that the Package Manager Project is a new project, and needs to be working properly on more platforms. Thanks for your email. I appreciate the feedback, from everyone. Take care. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sun, 26 Jul 2009 08:43:07 +0200, "Martin v. Löwis" wrote: > Hmm. I'm -0 on providing a tool whose only purpose is to download > files from a web server. I always use a web browser for that... It does a lot more than that. Firstly it shows what packages you already have installed and lets you manage them. Namely, deinstall, (manually) upgrade, view documentation and examples. In any case, even if it were only a tool to download packages it's still consistant with modern appliance design (mobile phones, programming languages, dedicated hardware) to have an internal application where a user can pretty easily download "checked" apps to their device/system. Nobody gives people just a browser to do that... and tell them "go browse". It isn't being done like that - except in python. > Hmm. I would expect that a new user is faced with the challenge > of finding out what packages to install more so than with actually > installing them. Yes. That's exactly the point. You're 100% right. That's why the pythonpkgmgr provides a useful search capability for pypi packages. It's faster and more natural to use a native app than do it all in the browser. That's true in Perl (cpan) as in Python and I'm honestly saying that I can't find any noteable faults in pypi the way I find it. > If they read examples, they will see import > statements, and then they have to find out how to make those work. > Does your tool help with that? Yes. It will open the website or homepage to the project/package in question. And find any documentation that might be stored in the package directory. If you only have "import interbasedb" it's a complicated process for a new user to located the home page or project documentation without pythonpkgmgr. Using pythonpkgmgr, they look on their list of installed packages, find the "interbasedb" or whatever module, and can get quick access to the pypi page or the package homepage. It's much easier. Much faster.. especially if the new user doesn't know the internals of package storage, pypi and the like. > When the user is not so new anymore, I seriously doubt that they > still ask for a package management tool - except perhaps for > dependencies, and here they use easy_install. Well, that might be one use-case. It's true that many python programmers will just want to stick to their own "known" packages. However, this tool aids people with more curiosity. Because users can so easily (and safely) install and deinstall anything. It's only a click to install a package, and another to deinstall. At the moment, pythonpkgmgr doesn't handle dependencies except that which is provided internally by easy_install/pip. I'm hoping to change this as my experience and understanding grows. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sun, 26 Jul 2009 18:05:07 +1000, Steven D'Aprano wrote: > But you shouldn't expect the > Python dev team to accept an unproven tool into the official library > before demonstrating both the need and the solution. Of course... that's why I started off by asking what the process is. I am accepting that the current status of pythonpkgmgr is "unproven" so it will need some time for things to run their course. > (Just because > users say they want something, doesn't mean they'll actually use the > tool you provide -- perhaps they don't know what they really need, and > perhaps your tool doesn't match their needs.) Conversely, the process of satisfying needs is to discuss them. And people have been ever so helpful in that regard. > I'm a user, and personally I don't want Yet Another Integrated Package > Management Tool. What I really want is the ability to install Python > packages using the PM tool I already use, namely yum. ok - but no alternative to that is available on windows. pythonpkgmgr is not so different to that. And the idea behind it is to bring consistancy in package management across the different platforms. It does have configuration that are specific to python, and will continue to do so. Like being able to specify where one wants the package installed. > Putting your software on the Cheeseshop, and making regular > announcements to the Python community (e.g. on comp.lang.python) will > be a good way to publicise the tool, and if does meet a need, people > will use it, and then, if it's good enough and popular enough and > supported, it may be blessed by inclusion in the standard library. Thanks very much. Take care. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Mon, 27 Jul 2009 11:18:25 +0900, "Stephen J. Turnbull"
wrote:
> [1] on
> my part") and sysadmin goals ("something that works and plays nicely
> with the rest of the system").
>
> pythonpkgmgr seems entirely oblivious to the latter issue, and not
> particularly compatible with the way package management works in *nix
> OSS distros (including Linux distros, but also *BSD, MacPorts, and
> Fink).
Well I'm a sysadmin on linux in my day job.
I'm entirely wondering what you mean by that ? I'm oblivious how?
What can a developer mode project, like pythonpkgmgr possibly do
except to make it easier to manage local package space?
A developer shouldn't need to do sudo every time they want
to put or try some python package from pypi. imho that's
wrong and I'm helping to reduce that need.
If the sysadmin puts a package in (/usr/lib/pythonX.Y/site-packages)
via the O/S package manager (ie synaptics/yum/apt) then that
should stick over what a developer is doing.
But the developer should be able to stick their own packages
in their own local space.
Correct me if my assertion is wrong.
David
___
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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sun, 26 Jul 2009 17:23:59 +0100, Michael Foord wrote: > It would be great to have a decent visual package manager for Python. Hopefully one day we'll have one - haha > It needs to be built on top of the work that Tarek is doing with > distutils (and be compatible with his Distribute fork of setuptools) and > it also needs to be established. I'm planning to support it - like I do for setuptools and pip > The good news is that there is time for both... Aren't there other tools > that have similar goals? PyPI browser, Yolk etc The fact is that there's way more glamorous things to work on than a package manager. Nobody has written a package manager for python imho simply because there's so many more fun things to do with python than that... > It is a shame that it needs to be built on Tk if it is to stand a chance > of ever being included in the standard library - but with the right > expertise it is *possible* to create decent looking UIs with Tk. I'm working on a TK version.. yes.. a TK version is better than nothing and the differences between a TK and a WX version is really only pretty minor. To me, wx is ancient... and tk is simply prehistoric. mr.new-to-python developer wouldn't really cares too much either I would suspect. All they want is to be up and running quickly. My only point is that Windows ain't no embedded system. It's not short on memory or disk space. If a package manager is 5 megabytes extra say, with it's libraries.. what's the extra download time on that ? compared to three days+ stuffing around trying to find out how to install packages for a new user. If the source needs to go in too.. that's a few kilobytes. That's like 57 extra bytes to an old-timer... I know.. it's such a sacrifice.. and we're all working on 300 baud... :-) David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Mon, 27 Jul 2009 19:29:14 +0900, David Cournapeau wrote: >> My only point is that Windows ain't no embedded system. It's not >> short on memory or disk space. If a package manager is 5 megabytes >> extra say, with it's libraries.. what's the extra download time on >> that ? compared to three days+ stuffing around trying to find out >> how to install packages for a new user. > > The problem is not so much the size by itself that more code means > more maintenance burden for python developers. Including new code > means it has to work everywhere where python works currently, and that > other people can understand/support the related code. Adding code to a > project is far from free from python maintainers POV. Well I concede that you might have a point. And I know there have been some issues in the past with package management in python and people being able to understand other peoples code. In this specific case, I don't think you'll find the same problems. pythonpkgmgr is not an entirely self inclusive project. It leverages on setuptools and pip. I want to extend it to enstall. If there is any preference towards setuptools - it's only by test-time availability. In windows, it's built with py2exe. There are some supporting .dll files that need to go with it from wxpython. They're both really mainstream python(windows) toolkits. Everything in pythonpkgmgr is transperant - and was designed to be. Otherwise there's no point. If any developers want to join the project with 'commit' privaleges on the source, I'll make sure it will happen. If not.. I'm very happy just continuing on with my own merry way... :-) David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Mon, 27 Jul 2009 20:12:54 +0900, "Stephen J. Turnbull" wrote: > Not you; pythonpkgmgr. You've said nothing about how pythonpkgmgr is > supposed to deal with multiple installed versions of Python Under windows it can deal with multiple versions of python. You just go to options and select which version of python you wish to manage. It's as simple as that. > or how it helps if you need a custom version of a > module, etc., or how it can help the developer's "local" modules > cooperate/not interfere with system versions, etc. It manages local developer modules for python 2.6+. As for checks, it doesn't have so many at present. But it makes it a lot easier to see what you have installed. So if something needs to be removed and reinstalled - it can do that. > Pave the road to DLL Hell with good intentions, of course. Well - there's plenty of that > > > A developer shouldn't need to do sudo every time they want > > to put or try some python package from pypi. > > I don't remember *ever* sudo-ing to try a package from pypi. ok. But if you were using an O/S level package manager you would have to enter a su password to start the tool. Because that is needed to load packages into /usr/lib/pythonX.y > I just don't understand what problem you're claiming to solve. Making it simpler for new users to find and install packages from pypi. And manage the existing packages that are installed on their machine. > The > problem of managing local package space is in some sense solved by > virtualenv, but you haven't mentioned that at all. I never heard of it till a few months ago. To my knowledge it doesn't offer a gui. I'm told it's good for certain things and I believe it. My problem was installing packages on windows boxes, not in the development. > Is pythonpkgmgr an > alternative? A complement? to virtualenv or zc.buildout? pythonpkgmgr is aimed at featherweight users. It could be highly complementory to both virtualenv or zc.buildout at some stage if it were customised to work with those. For example, it could work with virtualenv by having a a drop down list of the different 'environments'. I don't know how to do it right now - but I'm hoping I can figure it out sometime. With zc.buildout, there's no reason why it couldn't generate a package list in that format, or do an import from a manifest. pythonpkgmgr already can generate a list of local packages as a manifest - but not in the zc.buildout format. I'm sure in the future - I'll figure that one out as well. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sun, 26 Jul 2009 19:31:40 +0200, "Martin v. Löwis" wrote: >>> If they read examples, they will see import >>> statements, and then they have to find out how to make those work. >>> Does your tool help with that? >> >> Yes. It will open the website or homepage to the project/package >> in question. > > How does it know the project in question? Because it is either in the pypi search results or list of installed packages. > How do they find interbasedb in the list of installed packages if > they haven't installed interbasedb yet? They'd already installed it. But perphaps through a .exe installer. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Sun, 26 Jul 2009 19:33:37 +0200, "Martin v. Löwis" wrote: >> pythonpkgmgr is not so different to that. And the idea behind it is >> to bring consistancy in package management across the different >> platforms. > > At the cost of being inconsistent within a platform. It has the most generic of user interfaces. On Windows, a command line interface is the most out-of-place thing anybody could ask for. 19/20 kids these days wouldn't even know what a command line interface is until you show them. The first thing that they would look for is a GUI tool in the Python X.Y programs menu... So I respectfully say that there couldn't be anything less true than the assertion that a GUI package manager is inconsistent within a modern GUI desktop environment. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Tue, 28 Jul 2009 07:12:25 +0200, "Martin v. Löwis" wrote: > So there are now two incompatible ways to install a package: > either with the native manager, or with pythonpkgmgr. If you install > them one way, and try to remove them the other way, you lose. pythonpkgmgr is only a thin wrapper for easy_install/pip. If there is a problem, then it is already a pre-existing problem that is not of my doing. It's certainly true that if a python package is installed with a windows installer or as a .deb/.rpm, then that package should be uninstalled using the appropriate and corresponding tool. The same is true if the package was installed with either pip or easy_install. All I can do is put it in my tracker as a bug and deal with it later when I have time. Good point David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Tue, 28 Jul 2009 07:55:11 +0200, "Martin v. Löwis" wrote: > Yes, eggs have the same problem. That's one of the reasons they > don't get integrated into Python. Yes but egg_info is included in python... and the egg is not Hence, what goes in and what doesn't isn't always that rational. I'm just accepting that for the moment. David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Tue, 28 Jul 2009 11:50:00 +0100, Paul Moore wrote: > egg_info data is in to allow "standard" (setup.py install and hence OS > package manager managed) packages to provide metadata in a > discoverable way. Using a format that is (reasonably) compatible with > setuptools is simply a matter of co-operating with existing de facto > standards. > > Eggs themselves (as a distribution format) are just zip files with a > funny extension, and as such are supported by Python. ok - I get it. It's all one big monty python comedy thing where things are quirky and inconsistent - there's little continuety from one scene to the next but you have to stop sometimes and have a laugh... because to word quote from you - "funny" Your whole email whilst perphaps technically correct is terribly difficult for a software engineering person to follow. Monty python was only meant to be a funny film for entertainment, not a philosophy for building software from Why we can have the egg_info without allowing the egg is kind of like having a chicken and egg story without allowing the chicken.. or is it the egg.. oh I lost track... I think I need to watch the movie again to understand what's happening here... Let me go away confused... don't ask me any more questions or elaborate with more answers. Thanks. :-) David ___ 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
Re: [Python-Dev] Update to Python Documentation Website Request
On Wed, 29 Jul 2009 10:56:20 +1000, Nick Coghlan wrote: > The words "eggs" brings with it a whole lot more baggage than just the > sum of the technical parts in the language core that support them > (primarily distutils and zipimport). Well, in this case, (talking metaphorically) we have the ability to roll the eggs, crack a whole in them and suck out the contents (deal with a package in a zipped egg) So metaphorically we could say that python can work with egg shells.. As for what's in the egg... well lets just say that it's a bit floaty.. And perphaps that is the best way for things to be for a while. > I find it unfortunate that the name > for the distutils metadata format contains the word "egg" because it > implies much greater consensus around the philosophy behind eggs than > actually exists. I see it a different way. I thinks eggs are simple - as in like a java bean. A simple way to move a package from one place to another. What seems to have gone wrong is that there is a lot of pioneering and interconnected and interdependent technology within them. They're an egg.. but in the past they've had little monsters that bite your fingers when you try to put them in the pan... :-) I think "Egg" term is very good. But maybe we are best not trying to over-specify their contents. Maybe we should say it has certain things (EGG_INFO, PACKAGE DATA) as in (YOLK, WHITE) and pretty much leave it at that. If more detail is required - rtm. > A lot of the baggage associated with the "eggs" concept is related to > the inherent conflict between different approaches to dependency > management: That's not an egg problem. That's a packaging/metadata problem. It's the package dependency issue that's the problem. That's a distutils problem. > 1. Use the system package management system for everything (preferred by > many, perhaps even most, *nix sysadmins, but not an option on Windows) Yes, because the package dependency issues are just so great. > 2. Create a Python specific package management system independent of the > system package manager (an area dominated by setuptools, including both > eggs and non-zipped package distributions) More work needs to go into distutils. Not taking away from any existing work - but setuptools has relied on the deficiencies of distutils to gain a foothold. Fix distutils (give me time to think..) and the need for setuptools and any further fork is probably negated. > 3. Bundle everything into a monolithic application or framework (the > typical approach on Windows with py2exe, but also the philosophy behind > tools like virtualenv) Windows users are using py2exe and other products over distutils. To a normal windows developer, distutils makes imho no sense in the way that it goes about things now. For example, very simple concepts like "program directories", (where you stick the program) isn't an available option in distutils. But it is the first thing that you need to know in a windows program. So it's very hard to get to step 1... > Your comments about your > package management system suggest that it is just yet another entrant in > category 2 and you have said nothing to allay the concerns of those that > despise that philosophy with a passion because of the problems it causes > them when trying to manage their systems using the first philosophy. I'm a windows user.. I can't be in category #2.. I'm in category #1, have nothing... (except now my own tool) > Since the Python constituency includes developers and system > administrators that favour all 3 philosophies (and probably other > variants that I haven't thought to describe), anything that makes it > into the standard library will need to adequately balance the interests > of all parties (e.g. as has occurred in the PEP 376 metadata enhancement > discussions). Well at least you are saying that there is some way of reconciling all the different options... There's an awful lot to take in, and there must be 20,000 lines of emails for every 1 line of python code that is required to fix this thing. Take care David ___ 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
Re: [Python-Dev] request for comments - standardization of python's purelib and platlib
Hi Jan, It's not impossible, but you have some dependencies. If you can patch distutils within Suse, then it mightn't be so difficult. Distutils is not much more than a file copier. Inside distutils, a lot of the paths that you are talking about are hardcoded. > One, python depends on the "lib" directory. (from distro's point of > view, prefix is /usr, so let's talk /usr/lib) Due to this, it's > impossible to install python under /usr/lib64 without heavy patching. correction - light patching. > Repeated attempts to bring python developers to acknowledge and rectify > the situation have all failed (common argument here is "that would mean > redesign of distutils and huge parts of whatnot"). Make it a zope/plone issue... and something might get done about it haha If it's a windows or linux issue... pour petrol on it and light a match.. seriously... it's not major refactoring.. it's just changing a few conditional constants.. within distutils.. > Let's put our heads together and choose good default locations for > purelib and platlib. Then add support to python for recognizing the > locations by default, and possibly leave note in FHS that "this is the > place". Sure - discuss away. But you might end up having to patch your own distribution. > 2 - the sharedir way > purelib = /usr/share/python/X.Y > platlib = /usr/lib(64)/pythonX.Y/site-packages > > pros: > + clean separation of purelib - nice! > + unheard of - a good place to start anew > cons: > - FHS states that /usr/share is for data. But OTOH, they don't say much > about platform-independent bytecode. We could probably get an exception > for this. > - unheard of - everyone will be surprised +1 Go try... David http://sourceforge.net/projects/pythonpkgmgr/ ___ 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
Re: [Python-Dev] request for comments - standardization of python's purelib and platlib
Hi Tarek, What is needed is to remove/refactor the hardcoding of paths that currently exists within distutils and replace it with the ability to override the defaults via configuration files. (distutils.cfg?) If there's one thing that's certain for the future, its that python will go onto more platforms. Using different paths. When people are complaining about paths being hard-coded into distutils and it causing angst, I think that their complaints are valid. I can find posts going back to 2004 for windows users complaining about exactly the same thing. So it isn't a new issue. The problem applies to both linux and windows. Anyway.. do you know the code that we're talking about? David On Fri, 14 Aug 2009 10:02:03 +0200, Tarek Ziadé wrote: > On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon wrote: >> >> >> On Thu, Aug 13, 2009 at 11:23, Jan Matejek >> wrote: >>> >>> Hello, >>> >>> I'm cross-posting this to distributi...@freedesktop and python-dev, >>> because the topic is relevant to both groups and should be solved in >>> cooperation. >>> >>> The issue: >>> >>> In Python's default configuration (on linux), both purelib (location for >>> pure python modules) and platlib (location for platform-dependent binary >>> extensions) point to $prefix/lib/pythonX.Y/site-packages. >>> That is no good for two main reasons. >>> >>> One, python depends on the "lib" directory. (from distro's point of >>> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's >>> impossible to install python under /usr/lib64 without heavy patching. >>> Repeated attempts to bring python developers to acknowledge and rectify >>> the situation have all failed (common argument here is "that would mean >>> redesign of distutils and huge parts of whatnot"). >> >> This is now Tarek's call, so this may or may not have changed in terms of >> what the (now) distutils maintainer thinks. >> > > I don't recall those repeated attempts , but I've been around for less > than two years. > > You are very welcome to come in the Distutils-SIG ML to discuss these > matters. > I'm moving the discussion there. > > Among the proposals you have detailed, the sharedir way seems like the > most simple/interesting > one (depending on you answer to Brett's question ) > > > Regards > Tarek ___ 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
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Tarek,
Are you claiming this as your own work and ideas?
Given:
http://mail.python.org/pipermail/distutils-sig/2009-August/012998.html
Regards
David
On Tue, 22 Sep 2009 15:21:06 +0200, Tarek Ziadé
wrote:
> Hello
>
> Here's a wrapup of the Distutils-SIG discussion
> we had on the "static metadata" topic.
>
> I realize that it's a good thing to send in.
> python-dev such wrapup on distutils design
> decisions, to keep everyone informed and get
> more feedback when required.
>
> I will try to do it for every upcoming changes
> that are not going in a PEP process (when it's not
> a 'big' change). The rate of such mails should
> not be very high. (around 1 mail in python-dev
> for +150 mails in distutils-SIG)
>
> If you feel that what we are about to change in distutils
> is wrong, you can go ahead and help us by participating
> in Distutils-ML, so we keep one and only one media
> for these discussions.
>
> The four sentences summary for people in a hurry:
>
> Getting metadata of a distribution that is not.
> installed means running its setup.py. This means.
> downloading the whole archive, and running.
> third party code on your system.
>
> To avoid it, we are adding a [setup] section in.
> setup.cfg where you can express the package metadata
> statically.
>
> Conditional sections, specific to some system.
> can be added to add some specific fields in [setup].
>
> At the end, you will be able to get metadata fields
> without running any third-party code, and possibly
> get only the distribution setup.cfg for this.
>
> Now the long version.
>
>
> Rational
>
>
> Today, if you want to list all the metadata (PEP 314) of a.
> distribution that is not installed, you need to use it's.
> setup.py CLI.
>
> So, basically, you download it, and run::
>
> $ python setup.py --name
> Foo
>
> $ python setup.py --version
> 1.2
>
> Where `name` and `version` are metadata fields. That's OK but as.
> soon as the developers add more code in setup.py, this feature
> might break or (worse) might do unwanted things on the target.
> system.
>
> Why should we run third-party code just to get its metadata ?
>
> So we worked on a way to express those metadata statically,
> by pushing them in `setup.cfg`. That's not hard, since all.
> the metadata fields are static values.
>
> Adding a setup section in setup.cfg
> ===
>
> So the first thing we want to introduce is a [setup] section,
> that may contain any field from the metadata::
>
> [setup]
> name: Foo
> version: 1.2
>
> Distutils will look for them, and will use them. Of course
> setup.py is still required, and in case an option that is.
> a metadata field is passed to setup(), it will override one.
> located in setup.cfg.
>
> PEP 341 is coming up
>
>
> Remember the last Pycon Summit ? We said that we would
> introduce a new metadata field to describe requirements..
> That's basically what PEP 341 is about, and we are still.
> working on it.
>
> Basically, we will be able to write things like::
>
> requires: Twisted == 8.2.0
>
> What takes us so long is that adding requirements like
> this in the metadata requires more things:
>
> - the ability to compare versions (this was described in.
> PEP 386 but not finished yet)
>
> - the ability to make these requirements vary depending on.
> the target system
>
> And the later makes our "setup.cfg" new [setup] section.
> obsolete as soon as this new metadata field is added in.
> Python.
>
> So we need more that what I've shown in the previous section
>
> Context-dependant sections
> ==
>
> The second change we are going to introduce is context-dependant
> sections in setup.cfg.
>
> A context dependant section is a section with a condition that is.
> used only if the execution environment meets its condition.
>
> Here's an example::
>
> [setup]
> name: Foo
> version: 1.3
>
> [setup:sys_platform == 'win32']
> requires: pywin32
> requires: bar > 1.0
>
> [setup:os_machine == '64bits']
> requires: some_package
>
> [setup:python_version == '2.4' or python_version == '2.5']
> requires: some_package
>
>
> Every [setup:condition] section will be added in [setup]
> only if the condition is met.
>
> The micro-language behind this is the simplest possible:
> it compares only strings, with usual string operators,
> and with the ability to combine expressions. It makes it also
> easy to understand to non-pythoneers (os packagers).
>
> The pseudo-grammar is (I don't know how to write those but you'll
> get it hopefully)::
>
> comp: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'
> comparison: expr (comp_op expr)*
> expr: STRING
> test: or_test
> or_test: and_test ('or' and_test)*
> and_test: not_test ('and' not_test)*
> not_test: 'not' not_test | comparison
>
> where ST
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Hello Guido, > Isn't it clear from Tarek's email that he is summarizing > distutils-sig? Well, I'm new to this. Summarising is a word that could be certainly applied. > Isn't it odd that you ask this question pointing to > your own message? It's not odd at all. When I see my ideas, which Tarek originally argued against, published with his name on them, and my name left out, I just felt it fair to myself to ask him how that might have happened. > Are you worried that you won't get credit for the > idea (assuming it's yours)? As I said, I'm new. I've been very happy to help out. This is all a learning process for me. I can accept whatever decision Tarek makes on distutils and the direction of the code. If he chose to ignore my postings and go a different way from what I suggested then that is his perogative. If the failing was on my part to not fully write up PEPS and do full examples, and diagrams and so forth, then I accept that. > Should you perhaps just ask for credit instead of asking a > rhetorical question? I don't really believe that the work is complete enough for anybody to claim credit for just yet. That's why I was surprised to see the announcement. Hence me asking about it. In all fairness, I'm trying to help Tarek here. And the python packaging effort. Getting my name on what I believe are my contributions shouldn't be such a big deal and I'm very sure you'd agree on that. But it is an ongoing struggle for whatever reason that I've been having. I'm sure your guidance can resolve the issues easily.. David ___ 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
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, 22 Sep 2009 22:39:04 -0700, Brett Cannon wrote: > I don't think anyone on python-dev thought that it was exclusively Tarek's > idea or necessarily even mostly his. Actually, he originally argued against it, but that is irrelevant. I'm happy that he's come around and embraced it. Perhaps a bit too much could be my issue. > If you want explicit credit, you can co-author a PEP or get thanked in > a checkin as you mentioned. Good idea. How can I get check-in privileges on distutils ? What is the process? > But honestly, from my observations of open > source, ideas are not what get you noticed, it's producing something > tangible like code. Sure.. you're 100% right. So I need to be able to work on code and be able to check it in. I would love that. How do I get that? > Plus ideas and such pull from so many people on > mailing lists you can claim you came up with the initial idea, but I > am sure a ton of people provided feedback which makes ownership of any > idea practically moot. Claiming ownership? No No. Lets not go there. A worklist and checkin rights would completely suffice. David ___ 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
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Wed, 23 Sep 2009 09:49:16 +0200, "M.-A. Lemburg" wrote: > While it's a good idea to put up some form of meta-data > into an index, I wonder why you are using setup.cfg > for this. > > setup.cfg has traditionally been used to configure distutils, > not to define meta-data. As such you wouldn't want to > put such a configuration file up on PyPI. > > Wouldn't it be better use a new file for this (with the > same syntax), e.g. metadata.cfg ?! This would then just > contain the meta data that needs to be published. Forgive me if I answer this from being on the distutils-ml but it is easy to answer and might save somebody else time. Currently, the metadata is stored within setup.py and the biggest issue with that is maintaining the version number. For instance, getting the same version number to go into the documentation files, etc. So consensus was that keeping that information in setup.py is somewhat cumbersome and putting it somewhere else would be better. Tarek suggested setup.cfg and it seems to make the most sense. By moving the metadata values into a configParser format file, it would mean that external scripts could more easily access/update the version number as required. Of course, setup.cfg wouldn't get uploaded. Nobody would want to do that. But distutils would create the .PKG_INFO file and metadata from configuration, and not from hardcoded string values within setup.py as it does now. David ___ 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
Re: [Python-Dev] thinking about 2.7 / buildbots / testing
On Wed, 23 Sep 2009 15:13:55 -, exar...@twistedmatrix.com wrote: > Quite a few years of experience with a distributed team of build slave > managers has shown me that by far the most reliable way to keep slaves > online is to have them managed by a dedicated team. This team doesn't > need to be small, but since finding dedicated people can sometimes be > challenging, I think small teams are the most likely outcome (possibly > resulting in a team of one). > .. > Casual volunteers generally just won't keep up with these tasks. True. > I suggest finding someone who's seriously interested in the quality of > CPython and giving them the responsibility of keeping things operating > properly. This includes paying attention to the status of slaves, > cajoling hardware operators into bringing hosts back online and fixing > network issues, and finding replacements of the appropriate type > (hardware/software platform) when a slave host is permanently lost. Well, I'm a system administrator now, and a casual developer. Yes, you need somebody who watches machine control panels and can type emails on python lists at the same time. > I would also personally recommend that this person first (well, after > tracking down all the slave operators and convincing them to bring their > slaves back online) acquire shell access to all of the slave machines so > that the owners of the slave hosts themselves no longer need to be the > gating factor for most issues. Depends on where the machines are. There are good tools do check all automatically. Nagios is one. Anyway, this would suite my work schedule for the next 12 months. Do we already have the machines? or do they need to be acquired? David ___ 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
Re: [Python-Dev] eggs now mandatory for pypi?
On Tue, 06 Oct 2009 13:52:34 -0400, "P.J. Eby" wrote: > Btw, every couple years or so I've sent out a call on the > distutils-SIG to try to get consensus on a format for the platform > tag information used by setuptools. (The first time was before > easy_install even existed.) Unfortunately, it's rare that anybody > contributes more than criticism of the existing scheme. The last > updates to the scheme were by Mac folks, who at least had a clear > vision of what was needed. There's been some win32/win64 discussion > in the past, but no proposals or patches of comparable > specificity. Consider the fact that Mac users won't answer or discuss posts by some windows users.. Why do this ? Why stir up platform bias? Fact is Phil, windows users get *turned-away* at the door in distutils... or ignored. Issues can hang around for years. And your post is now asking "why no windows users?" Go figure.. nobody answers them or takes issues seriously. Distutils for windows is very, very dead.. grave-ware in-fact. It should be quite obvious that windows users are forked off.. Why would windows people make proposals when they know it won't go anywhere... David ___ 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
Re: [Python-Dev] eggs now mandatory for pypi?
On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers wrote: > Well yeah, and the only sane way I can think to handle this is to have a > metadata file that gets uploaded with each distribution that covers all > these things (and the other things that other people need) and then have > the index (which would hopefully be PyPI on the whole) be queryable > along the lines of "give me a download url for a distribution named X > that is for Python 2.6, Win32, UCS4, PostGreSQL 8.5, BlagBlah"... Exactly. I'd like to see that and it sounds like a very simple and reasonable proposal. One could say that much of the setuptools cloud came about because of the lack of the queryable download url. Setuptools does a lot of work here to 'work-around' the ommission on pypi of a package download url. I'm just with you 100% on this... David ___ 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
Re: [Python-Dev] Distutils and Distribute roadmap
On Thu, 8 Oct 2009 21:41:21 + (UTC), Antoine Pitrou wrote: > I think it's quite trivial actually. Since everybody agrees (except perhaps > PJE) > that Distribute should replace setuptools, the word will spread and trickle > quite quickly in the various layers of the community. I don't think that it's that black and white. PJE put a lot of work (and creativity) into setuptools. There's some degree of tragedy if his project gets forked off simply because of failures in the testing and quality assurance department. Personally, I find the setuptools code somewhat hard to follow. The style goes back to early programming by 'masters' where the only person that could follow it was the master himself. Sadly, that is not what we need in open source. The newer trend is in highly readily readable and easy to understand code. Tarek is excellent at producing high quality code of the type that is required. But his programming world (on the mac) isn't full of the challenges that we poor other unfortunates face on other platforms face. Coming back to the point, setuptools is a pretty poor package to have to fork. It's very difficult to follow and the structure and implementation is cryptic. Perphaps it's a thankless job that Tarek has taken on in that regard - but he seems to be handling the distribute fork quite well. Being new to python, it's taken me a little while to figure out the process. But I've decided to write a static metadata pep which is underway now as an alternate proposal. Being primarily a hacker, writing nice design documents doesn't come easy. If there is any distutils roadmap, I'd like to see improvements that work on Windows. Yes.. python does work on windows and we can't all get our bosses to change to os-x just yet. There's many things in distutils that I could best describe as being unfinished or partially done. Let me make a few rambling direction suggestions... - command line package installation for distutils We need a simple script, not based on setuptools to allow installation, listing and deinstallation of packages. Currently *nothing* exists in distutils to do this. It's a **major** failing. - Improvements to operation on platform Windows Package/Application installation on windows sucks... For example, there's no documented way to get your programs installed to "\Program Files\myApplication" For non windows users, that's where programs are supposed to go. Any other place is "evil" - like where they are going now. If it is only a documentation issue, well can we fix that. All I'm asking for is a matching "elif sys.platform = 'win32'" for every "if sys.platform = 'darwin'" or less. It's not unreasonable... It's probably a sensible idea for Tarek to keep going with Distribute. My user experience with setuptools was that it wasted a lot of my time unnecessarily. I'm planning to put Distribute support in the Python Package Manager project (pythonpkgmgr) for it's next release. David ___ 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
Re: [Python-Dev] eggs now mandatory for pypi?
On Thu, 08 Oct 2009 09:35:57 +0200, "M.-A. Lemburg" wrote: >> One could say that much of the setuptools cloud came about because of >> the lack of the queryable download url. Setuptools does a lot of work >> here to 'work-around' the ommission on pypi of a package download url. > > I think you two have missed my email to PJE. > > In summary: > > PyPI already does have mechanism for querying download URLs. > > http://wiki.python.org/moin/PyPiXmlRpc > > It only lacks some more meta-data that would be required to > match up the user's configuration with the one used in the > uploaded URLs. > > And it would be handy to have a mechanism to just upload the > URL data rather than the whole package. Looking at distutils' > upload command, PyPI currently appears to only support uploads > of the package file itself. > > Basically, most of the mechnisms are already there, they just need > some extra care. Maybe you're right. I'll look into it. > BTW: Who would I need to contact for the PyPI side to work out > an upload_url distutils command ? pypi is on sourceforge... ask to become a developer I guess.. David ___ 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
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Fri, 09 Oct 2009 17:49:23 +0100, Michael Foord > I wonder if it is going to be possible to make this compatible with the > upcoming distutils package management 'stuff' (querying for installed > packages, uninstallation etc) since installation/uninstallation goes > through the Windows system package management feature. I guess it would > be eminently possible but require some reasonably high level Windows-fu > to do. It's a good question. Searching on it turned up no easy way of doing control panel applications in python. A much easier way would be to just mount a package manager application in the "Programs" + "Python X.Y" menu. Users would surely find it there. Regards David ___ 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
Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Tue, 20 Oct 2009 21:49:42 +0100, Paul Moore wrote: > Can I repeat that in big letters? The key is a SINGLE DISTRIBUTION FORMAT. ok - but that pretty much exists.. > If you can persuade everyone to accept a format which ignores clearly > stated user requirements, go for it. But if you can't, you're making > the problemorse rather than helping. My money's on a solution that > acknowledges and addresses user requirements instead. What solution is that exactly? You don't say.. I would be happy to revamp pythonpkgmgr and backgrade to have a tk interface if it is felt that would help. That's not so difficult - certainly not on my side. I don't know which iceberg the people that want to keep command line interfaces forever still live on, but they seem very good at sinking any attempts of passage by forward moving boats.. Distutils roadmap for windows is to apply more freeze spray.. it's a cryogenic source code freezing iceberg... It's just there for windows users to crash their boats into.. Try and see for yourself.. David ___ 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
[Python-Dev] Python Package Management Roadmap in Python Releases
Hi All, I started out some time ago and wrote a Python Package Manager with wxpython. It was an interesting learning experience for me. I was new to python. Some have pointed out that using wx was not a good idea for a tool to go into all the python distributions. Because it required the external dependency of wx. So, given that, I'm ready to have another go. Some have suggested using Tk. But I noticed python Tk isn't standard on ubuntu. A console mode tool is possible. That would be better than the nothing that we have under windows today. Vote [1] - console mode tool for this Alternatively, a web server based tool along the lines of the old python docs system might be possible. Vote [2] - web tool for this I have come to understand that python-dev is full of people that know the packages that they like, know how to install them by hand, and probably only ever go looking for upgrades. However, for new users, it is so much harder. It also seems to me that we have a lot of reasonable and talented people, who are committed and dedicated. To me, a relative outsider, it's not clear if this is a python central issue, or a distutils issue. It could be either. Advise me please. By June next year, some people including myself, want to go to europe for holidays - sorry conferences.. and we want to take some work with us to talk about. We can do the work.. But we need concessions... What can we work on that might make a difference ? If the current roadmap for distutils package management on windows for the next 8 months is nothing, I can live with that. But seriously, lets get this discussion going again. If a command line tool is all that windows users will allowed to have, then it would be better than the current plan which is for them to have nothing. It's not just nothing for now, it's nothing for years. That doesn't seem fair or nice. It's not just one person saying that, it is a handful who don't use windows on a regular basis. Why can't we have an advocate from each major platform? bring their issues, and try to come to a consensus. Even if that tool would simply allow them to choose: - PIP - Distribute - Easy Install - Python Package Manager >From there, users could explore each offer on it's own merits. I'm interested in getting all types of opinions and feedback. David ___ 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
Re: [Python-Dev] Python Package Management Roadmap in Python Releases
On Wed, 21 Oct 2009 17:56:57 -0700, Brett Cannon wrote: > but I don't see why python-dev should have input on that sort of thing. python-dev is the only place where we could get a change to the installation binary release. We'd need a change and the addition of a program shortcut. > If you want distutils to expose something to make it easier to write your > tool then that belong on the distutils-sig. But otherwise this seems > off-topic for python-dev. I didn't ask for that - because I know that getting that assistance on the distutils side is certainly possible. Distutils is simply just one of the many libraries within python. It doesn't have an external interface. The roadmap for distutils for windows doesn't include getting a shortcut or utility for windows so that's why I'm asking about it here. Surely logic says that if it's 'python' and 'development' and it's not in distutils then some discussion of it should be allowed here. What I am really talking about is the menu shortcuts in the cpython distribution for windows. And how they can be improved to help windows users. This is the only place that I can think to discuss that. Best Regards David ___ 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
Re: [Python-Dev] Python Package Management Roadmap in Python Releases
On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon wrote: > But that assumes you can get your tool into the stdlib. No I'm not assuming that I can. I am actually assuming that I cannot.. So lets move forward.. > It would have been > better to phrase the question as "is there interest in having a package > manager tool included with Python" rather than ask us out of the blue what > GUI you should use. ok - but I think I know the answer to that.. you answer it next. > David, you are making a huge leap here thinking that we even want a package > manager in the stdlib. Well - who is 'we'? If it's python-dev people I can accept and respect that. If it's regular developers out there in developer land, I'm not so sure about your assertion. I'd even politely have to disagree from my experience. > You did not ask about menu shortcuts but whether a > package manager should be written using Tk or a web front-end. I was thinking about the issue on the fly... Menu shortcuts that link off to a a standard community web page would be an excellent compromise - in the case where some tool could not be added. That would be a tremendous improvement for windows users over what they are given at the moment. > Then you > start discussing about wanting to add some UI to package management by > default on Windows or add some tool that sounds like what the EU is going > to > have MS stick in front of users to get new user by browsers. This extends > beyond adding some shortcut the Windows installer adds to someone's > machine. That's going further than what I'm saying.. > I realize you are trying to help, David, but you are going in the wrong > direction here and pushing rather hard. On the counter side, others are pushing rather hard for 0 improvement for the windows platform for the user experience. While everything else on windows rushes ahead.. My direction is improving the developer experience for windows users. I can't do compiler writing. I'm not clever enough. > At the language summit we discussed > opening up some APIs in distutils about making it easier for people to > write > package management tools, but we don't have a burning desire to get into > the > tool business. ok - but nothing happened there... I'm not in the tools business either. I'm not doing it for money but that shouldn't be the point. > We make a language here. Distutils exists as a bootstrap > mechanism for the package story and for our own building needs of the > stdlib. I accept that it's a tool for building stdlib. No debate. > But I doubt I am the only core developer who has no interest to be > in charge of a package management tool when there already exists several > good ones out there that people seem to find on their own without issue. umm.. I disagree with the 'without issue' statement. I'm sure if I tralled the mailing lists I could find more than one.. Enough from me for now. Thanks Brett. David ___ 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
Re: [Python-Dev] Python Package Management Roadmap in Python Releases
On Thu, 22 Oct 2009 10:20:03 + (UTC), Antoine Pitrou wrote: > (*) Remember, however, that Tarek and work on Distribute, and also on > bringing pieces of setuptools/Distribute functionality into distutils. But if that's the case then why not work on any third party tool..? like pip or setuptools? It seems are very longwinded process if the only way to work on python is to work on distutils but before doing that you have to first work on distribute and then wait for all the changes to work their way back up the chain.. Actually, I have finally worked out what I want. That is shell support in the python windows distribution so that you can right click an .egg and install it. I don't see how that can be achieved by following the workprocess that you describe above. David ___ 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
Re: [Python-Dev] Refactoring installation schemes
On Wed, 4 Nov 2009 13:29:35 +0100, Tarek Ziadé wrote: > I've started to refactor the code in a module I have called > "sysconfig", reusing distutils/sysconfig, distutils/command/install > and site code. > > This "sysconfig" module should provide at the end very useful APIs to > query the current Python environment. > > That's a work in progress but: I've started a branch at > /python/branches/tarek_sysconfig so it's easier to get some feedbacks > if anyone want to help on this. Good job so far. Keep going. imho a refactoring of the installation and build schemes of distutils is due. It seems like you easily have the skills to do it. My advice would be to do it gradually, as you are. And focus on simplification, and filling in the functional gaps. Ask people what the functional gaps are on their platforms and try to mould it together in an unplatform specific way. Myself and others can assist with this, but best to do it on distutils-sig. I would even go so far as to use the python 3 as a carrot for the new work. imho The biggest and best thing that you could do for python packaging is to do a refactor of the .EGG format. What I mean here, is *take* the egg, and run with it. Modernise it and revamp it into a platform independent thing. People 'get' the egg idea, they just hate the current implementation. What we all *need* is for the egg to be what the source distribution now is. Not for it to be some proprietory out out of python object. Call it the new Tarek egg... Then refactor distutils build to focus on good egg creation.. Many people will help you.. including myself.. David ___ 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
Re: [Python-Dev] Refactoring installation schemes
On Wed, 4 Nov 2009 17:40:35 -0500, Fred Drake wrote: > The packaging story is in such bad shape that it needs the work > regardless, and keeping it to Python 3 would significantly reduce the > set of potential volunteers. Well I guess that is a 'marketing decision'. Not a coding issue. Actually, I don't honestly think that there is a lack of volounteers or any lack of resources. The main challenge imho is to get peoples bikesheds (including my own bikeshed) to line up in such a way that people can ride together sharing some sort of parts. Tarek has been doing just fine at facilitating this. > There's certainly work on that, but... is it that people hate the > format? Or working with setuptools? In my experience, working with the setuptools implementation is the difficult part. There's a barrage of impossible to remember command line options and the documentation is imho more convoluted than it needs to be. Let me put the distutils documentation forward as some sort of reference as to where the setuptools documentation should be. Then, there are some relatively minor issues that just annoy users to no end. The simple one is that they live in your site-packages directory unpacked. People wouldn't have so many issues if they lived like every other 'normal' package. As for the format itself, there's nothing to hate that I can see. > The fact that there's more than one egg format doesn't help, so you > may be right. Yes. The implementation can be confusing. That's the only problem imo. >> Call it the new Tarek egg... > > The tegg? ;-) l'oeuf ? In summmary, it doesn't matter so much what an 'egg' is. All that is important is that it works on lots of python platforms, distutils can easily pop them out, they are well documented and relatively trouble free. Most importantly, credit for the original idea goes back to PJE and everything gets refactored to make it 'nice'. I don't think it's a massive refactoring operation myself, and I'm very sure well within Tareks skillset to take on. David ___ 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
Re: [Python-Dev] Refactoring installation schemes
On Thu, 5 Nov 2009 11:35:41 +0100, Tarek Ziadé wrote: > PEP 376 is working on a default, unified, *installation* format, that > tries to gather the good ideas of Pip, Setuptools etc.. and propose a > unified format for our site-packages. This new standard will come with > APIs in pkgutil to be able to query installed distribution etc. This > work is also linked to PEP 345 work where we are modifying the > Metadata, and to PEP 386 that proposes a standard version comparison > scheme. Perphaps.. But if you put all these PEPs together, implementing all the new features can't come to more than 300 lines of code... Since we hardly got anywhere on them in 2009, it will be interesting to see how much of it gets done in 2010. > But there's no plan to include a new *distribution* format in Distutils. I wasn't suggesting that - at all. And saying that 'eggs' are a *new* python package format isn't really really helpful because to my understanding they've been around for some number of years. No, i won't raise why we have EGG_INFO directories and a whole lot of half working egg stuff in standard python... I'm just asking why it can't be more consistant? while we're on the refactoring topic. Be fair... I'm saying finish what is already there.. or take out the crap .. It isn't fair to suggest that I am somehow asking for some big change when I am simply pointing out all the junk that's in there that's already half built. > In any case those PEPs are not finished yet, so everyone can help at > distutils-SIG True - and False. But I've been on the list for some twelve months asking for work to help out with, and haven't been assigned a single task to do yet. Seriously, if you won't allocate work out to people then how can it get done? Whilst I personally think a lot of the stuff in those PEPs is not high on quality, why don't we just get them implemented anyway? I'm a fairly proficient develper, but I can't get assigned a single work item.. And to me, it doesn't seem any harder than just selecting 'djlyon' on the python tracker for some work items... Surely those PEPs all amount to 300+ lines of code. With two people working on it, that's only surely 150+ lines of code each... That shouldn't be such a big challenge for 2010.. David ___ 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
Re: [Python-Dev] Refactoring installation schemes
Tarek, Guido, Forgive my grumpy tone.. Looking positive, if we now have a rough consensus that the PEPS might represent some 300+ lines of code... then good - lets get started, that's all that I meant. I'm glad above all, that you noticed that part foremost. If it's a simple case that alternative's to the solutions cannot be considered - because I am grumpy - whatever, then that's something I can live with. I didn't know that proposing a different solution wasn't a good idea. > PS. Submitting a counter-PEP to the peps editors that hasn't been > discussed on the SIG list at all is also a bad move. You really need > to change the way you try to interact with the SIG. Here are the references to the discussions from distutils-sig. In these references you'll see that my interaction with the list was not grumpy but was entirely positive. I feel that I got a fair hearing on distutils list and I had a number of supporters to my proposal. The proposal is in the final stages of being wrapped up. Here are the discussion References that have occurred over the year: http://mail.python.org/pipermail/distutils-sig/2009-November/thread.html November 2009 Archives by thread * Messages sorted by: [ subject ] [ author ] [ date ] * More info on this list... Starting: Sun Nov 1 09:31:46 CET 2009 Ending: Fri Nov 6 00:09:22 CET 2009 Messages: 65 * [Distutils] Alternate static metadata PEP submission... Georg Brandl o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... Floris Bruynooghe + [Distutils] Alternate static metadata PEP submission... Georg Brandl + [Distutils] Alternate static metadata PEP submission... David Lyon # [Distutils] Alternate static metadata PEP submission... Georg Brandl # [Distutils] Alternate static metadata PEP submission... David Lyon http://mail.python.org/pipermail/distutils-sig/2009-October/thread.html # [Distutils] Alternate static metadata PEP submission... David Lyon * [Distutils] Alternate static metadata PEP submission... Tarek Ziadé o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... Tarek Ziadé o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... Eric Smith o [Distutils] Alternate static metadata PEP submission... Tarek Ziadé o [Distutils] Alternate static metadata PEP submission... David Lyon * [Distutils] Alternate static metadata PEP submission... David Cournapeau o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... David Cournapeau * [Distutils] Alternate static metadata PEP submission... Floris Bruynooghe o [Distutils] Alternate static metadata PEP submission... Tarek Ziadé o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... Tarek Ziadé o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... Floris Bruynooghe o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... Tarek Ziadé o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... Ian Bicking o [Distutils] Alternate static metadata PEP submission... David Cournapeau o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... David Cournapeau o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... Fred Drake o [Distutils] Alternate static metadata PEP submission... Kevin Teague o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... David Cournapeau o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... David Cournapeau o [Distutils] Alternate static metadata PEP submission... Fred Drake o [Distutils] Alternate static metadata PEP submission... David Cournapeau o [Distutils] Alternate static metadata PEP submission... David Lyon o [Distutils] Alternate static metadata PEP submission... David Cournapeau
Re: [Python-Dev] Refactoring installation schemes
Tarek, > Your proposal is a partial alternative to PEP 390, and is a quite > interesting work to dig in, and the SIG is discussing it, > but a very important point about it is that it does a lot more. It's a > new *building* system on its own, and does not limit itself to > describing metadata fields. Actually no, the proposal is only for a metadata installation of packages that addresses the security problem of requiring users to run untrusted and unverified setup.py's. That was where this discussion originated and that is what I am addressing. PEP-390 doesn't go there at all... My proposal uses the static metadata contained within existing package formats (PKG_INFO + sources.txt) and therefore doesn't require any changes to the build system. There isn't a new build system. I never proposed that. However PEP-390 does imply changing the build system. > That's why you can't just drop a counter-PEP to any existing PEP we > have started for Distutils. Imho help us build those PEPs, and / or > create your own build system, wether its based or not on Distutils. Once again, I can't see why all the fuss. All I did was have a discussion on distutils-ml about a different way of specifying package dependencies that might work across different python platforms. It was suggested to me that I do a PEP.. So I took the documentation on face value that developers could submit a PEP-proposal. > Imho help us build those PEPs, This could best apply to PEP-345: (PKG_INFO) Requires: sys Requires(python <= 2.4): lxml Requires(windows): win32com Requires(linux): pyodbc Requires(linux ubuntu gnome python <= 3.4): gix Requires(windows xp python < 2.2): win32prn Thank's for reading my alternate-metadata installation proposal and I accept your feedback. What I can do is clarify that my proposal is not for a build system but for a metadata installation scheme based on a static setup.py, existing metadata and use of "python -m setup install" for invocation. I'm just trying to make this stuff no more complicated than it needs to be... David ___ 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
Re: [Python-Dev] PyPI comments and ratings, *really*?
On Fri, 13 Nov 2009 00:44:30 +0100, Xavier Morel wrote: > If pypi one day has a CPAN-style buildbot farm allowing it to test the > package on any platform under the sun, that can be included, the tests can > be included as well but given the number of testing solutions (and coverage > discovery associated) that would be quite an undertaking. I'm working on such a thing in my spare time. Yep, it's a big time commitment. http://bitbucket.org/djlyon/pypi-package-testbot/ > And as far as docs go, what would be the criterion? "Has documentation"? Yes. > How do you define "has documentation"? Has auto-extracted documentation > from the docstrings? Yes. > Has a README? Yes Has a complete sphinx package? I don't think there's much that you can rate "objectively" about documentation. You can't do it objectively, but you can use a computer to count the number of lines and come up with a score. Daivd ___ 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
Re: [Python-Dev] PyPI comments and ratings, *really*?
Hi All, What do people think about this idea? I've actually started writing something to try to to do this and create sn automated scoring system for the packages on pypi. It was started last week based on Guido's comments on the distutils mailing list. > Why not rate ( or auto-rate) packages on > objective criteria? > > E.g.: tests and test coverage, docs, installs on python version X, Y, > Z, works on windows, etc? > > Quality can be measured. Me being a total failure and not reading the > docs, and failing to install something is subjective. I don't disagree > with the goal of giving *users* a voice, but is PyPI the right place > for that? How many moderators do we have to watch comments? Can other > users down vote comments by people which are simply *wrong*? > > Why can't we just disable it until we can come up with a better system > that finds a balance between the rights of maintainers, and those of > the user? ___ 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
Re: [Python-Dev] PyPI comments and ratings, *really*?
On Fri, 13 Nov 2009 01:14:54 +0100, "Martin v. Löwis" wrote: > http://pycheesecake.org/ Ok, so what is the current status on it? David ___ 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
Re: [Python-Dev] PyPI comments and ratings, *really*?
On Fri, 13 Nov 2009 01:27:47 +0100, "Martin v. Löwis" wrote: > Not sure; you would have to ask Grig. Apparently, there is a service > running somewhere that computes cheesecake data for PyPI packages; > it also sends them to PyPI. People have expressed to concerns that any > kind of ranking based on kwalitee sounds fairly useless. Of course. "Package Quality Metrics" would be a much better term. Still, the ideas they had were good. CPAN runs such a bot on all packages daily. Obviously they do it on seperate machines. Introducing any change is going to have people complain. Checking package authors packages is much like a dentist check. It mightn't be totally pleasant while its happening. But then if it isn't done, a user can then reflect and ask why nothing is being done to look at overall package quality. Which is currently the case. Processing so many packages for so many platforms is a monstrous task. Nobody should get the idea it can be done by the weekend. It will take a few months... well at the rate I am going anyway.. David ___ 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
Re: [Python-Dev] First draft of "sysconfig"
Hi Tarek,
Is there anything in this proposal for windows developers ?
Just that I can't see anything that would help us...
For me, the terminology isn't anything a windows developer could
really understand. It presumes that the developer understands the
python implementation. A developer might not understand all those
details and might not be interested to learn.
I accept that the terminology is good on linux.. but it's near
meaningless on windows - for me - anyway.
David
On Sat, 12 Dec 2009 21:02:13 +0100, Tarek Ziadé
wrote:
> Hello,
>
> A while ago I've proposed to refactor the APIs that provides access to
> the installation paths and configuration variables at runtime into a
> single module called "sysconfig", and make it easier for all
> implementations to work with them.
>
> I've started a branch and worked on it, and I'd like to ask here for
> some feedback. And in particular from Jython and IronPython people
> because they would probably need to work in that file for their
> implementation and/or propose things to add. My understanding is that
> we have people like Phillip (Jenvey), Michael F., Frank W. in this
> list so they can comment directly and I don't need to cross-post this
> mail elsewhere.
>
> == Installation schemes ==
>
> First, the module contains the installation schemes for each platform
> CPython uses.
> An install scheme is a mapping where the key is the "code" name for a
> directory, and
> the value the path of that directory, with some $variable that can be
> expanded.
>
> Install schemes are stored in a private mapping, where the keys are
> usually the value of os.name,
> and the value, the mapping I've mentionned earlier.
>
> So, for example, the paths for win32 are:
>
> _INSTALL_SCHEMES = {
> ...
> 'nt': {
> 'stdlib': '$base/Lib',
> 'platstdlib': '$base/Lib',
> 'purelib': '$base/Lib/site-packages',
> 'platlib': '$base/Lib/site-packages',
> 'include': '$base/include',
> 'platinclude': '$base/include',
> 'scripts': '$base/Scripts',
> 'data' : '$base',
> },
> ...
> }
>
> where each key corresponds to a directory that contains some Python
files:
>
> - stdlib : root of the standard library
> - platstdlib: root of platform-specific elements of the standard library
> - purelib: the site-packages directory for pure python modules
> - platlib: the site-packages directory for platform-specific modules
> - include: the include dir
> - platinclude: the include dir for platform-specific files
> - scripts: the directory where scripts are added
> - data: the directory where data file are added
>
> All these directory are read and used by:
> - distutils when a package is installed, so the install command can
> dispatch files in the right place
> - site.py, when Python is initialized
>
> IOW, any part of the stdlib can use these paths to locate and work
> with Python files.
>
> The public APIs are:
>
> * get_path_names() : returns a list of the path names ("stdlib",
> "platstdlib", etc.)
>
> * get_paths(scheme, vars) : Returns a mapping containing an install
> scheme.
>- "scheme" is the name of the scheme, if not provided will get the
> default scheme of the current platform
>- vars is an optonal mapping that can provide values for the
> various $variables. Notice that they all have
> default values, for example $base == sys.prefix.
>
> for example: get_paths('nt')
>
> * get_path(name, scheme, vars): Returns one path corresponding to the
> scheme.
>
> for example : get_paths('stdlib', 'nt')
>
> Those API are generic, but maybe we could add specific APIs like:
>
> * get_stdlib_path('nt')
>
> These API are basically a refactoring of what already exist in
> distutils/command/install.py
>
> == Configuration variables ==
>
> distutils.sysconfig currently provides some APIs to read values from
> files like Makefile and pyconfig.h.
>
> These API have been placed in the global sysconfig module:
>
> * get_config_vars(): return a dictionary of all configuration
> variables relevant for the current platform.
>
> * get_config_var(name): Return the value of a single variable
>
> * get_platform(): Return a string that identifies the current
> platform. (this one is used by site.py for example)
>
> * get_python_version() : return the short python version
> (sys.version[:3]) -- this one could probably go away but is useful
> because that's the marker used by Python in some paths.
>
> == code, status, next steps ==
>
> The code of the module can be viewed here, it's a revamp of
> distutils.sysconfig:
>
>
http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
>
> I've refactored distutils/ and site.py so they work with this new
> module, and added deprecation warnings in distutils.sysconfig.
>
> All tests pass in the branch, but note that the code is still using
> the .h and Makefile files. This will probably be rem
Re: [Python-Dev] First draft of "sysconfig"
On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond wrote: > I think it is fine. If you are really looking for properties specific > to the operating system (eg, the location of the start menu, desktop, > appdata folders etc) But under windows, an application developer might (as in probably would) like to install an application in \Program Files\someapp rather than hidden in the bowels of the python interpretor. They might like their data in "Application Data", which is where support people get trained to look for application data. Not down in \pythonX.Y\ ... > I don't think they belong in this PEP; they are a > property of the OS install/version, not of the specific Python > install/version. Yes - exactly. My point. The operating system says that programs should be installed into "Program Files" and data into "Application Data". Why can not python respect the operating system directions for well behaved apps? David ___ 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
Re: [Python-Dev] First draft of "sysconfig"
On Mon, 14 Dec 2009 23:58:08 +0100, Tarek Ziadé wrote: > Yes that's one point someone raised (can't recall who) and the idea was to > have a separate top directory for user dirs, that would start with the name > of the implementation: > > so for Windows: > > ~/Python/Python26/.. > ~/IronPython/../ > ~/Jython/../ I follow your reasoning. But application developers (and traditional windows developers) have an upside-down view of that. They might think that python is just the language interpreter, and that it should just stay 'out-of-the-way'. For example, mercurial and many python based apps include the python as a sub-app to their own. Just neccessary to run the application. That is the way it is for commercial windows apps. We want the python interpretor installed, and then we want our apps (that we get paid money for) to sit at the top. Not the other way round, sitting beneath the language interpreter. This is pretty much the way it has been for windows for close on 15 years now. Regards David ___ 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
Re: [Python-Dev] First draft of "sysconfig"
On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond wrote: >> But under windows, an application developer might (as in probably >> would) like to install an application in \Program Files\someapp >> rather than hidden in the bowels of the python interpretor. > > I agree - but in that case you are talking about an application built > with Python - that is a different set of requirements. Building an application with python.. that's right. Of course. Why not? > IOW, this isn't designed for applications which happen to be written in > Python. There might be a case for such a module to be created, but this > PEP doesn't attempt to solve that particular problem. But programmers might want to write an application with python. It doesn't seem like such an edge-case thing to do. >> They might like their data in "Application Data", which is where >> support people get trained to look for application data. Not down >> in \pythonX.Y\ ... > > Nothing is stopping them from doing that - but this PEP isn't intended > to provide that information. Distutils is stopping them. > It does - many applications written in Python exist which do exactly > that. Yes. And they don't use any of the built in facilities, under windows. > If a user really wants to install Python itself under "\Program > Files", sysconfig should correctly reflect that. Python doesn't care > where it is installed, or even when it is (sensibly) bundled with an app > which is designed to be "stand-alone". No debate about that. > You are after operating system properties - I understand your need to > know those paths (and there are already reasonable Windows specific ways > to get them), but sysconfig isn't trying to solve that for you and I > agree it should not attempt to. So under windows, then, what is it trying to solve? Thats what I am asking. David ___ 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
Re: [Python-Dev] First draft of "sysconfig"
On Tue, 15 Dec 2009 15:24:36 +1100, Mark Hammond wrote: But under windows, an application developer might (as in probably would) like to install an application in \Program Files\someapp rather than hidden in the bowels of the python interpretor. > ... > I'm missing your point The point is that if somebody writes an application in C, they will generally speaking not want (under say linux) for that application to live in the C compiler directory. Same goes for many other languages. The point is not controversial in other languages. And it shouldn't be here either. >> Distutils is stopping them. > > I don't agree with that and I can present many applications as evidence. Please do - if you wish. > You yourself mentioned mercurial and it looks for mercurial.ini in the > user's appdata directory. Sure. There's growing support within the python interpretor for things like that. But Mercurial uses an external installer. Like NSIS, to overcome the deficiencies that I am pointing out. > .. it isn't targetted at application developers on any operating system. I see. I get it now. Thanks. David ___ 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
Re: [Python-Dev] First draft of "sysconfig"
On Tue, 15 Dec 2009 09:32:55 +, Floris Bruynooghe wrote: > If I write a shared library under C I am expected to install it under > one of the default locations if I don't want to require people to have > to tweak things before they can use it. I see no difference with > python modules or packages. Any private modules or packages used by > an application built using python don't have to be on the sys.path by > default (in fact I would encourage them not to be). Hi Floris. Well Mark Hammond summed up for me - I'm satisfied with his answer. You're talking about modules and packages and I agree with you. I guess I was asking about was extending the set to of things that could easily be dealt with by python from just modules/packages to modules/packages + applications. What do I mean by an application?, well it's one or two steps up from the simple as 'helloworld.py'. There's lots of machines in the company, and lots of different apps. Not unlike a scientific area where there is lots of specialised equipment and each machine has slightly different requirements as to its function. Installing python is painless. That's all good. Installing all the python-packages has a learning curve and isn't very streamlined. In the end, it can be made to work. Installing the application (helloworld.py for the want of a better name), well, there isn't much in python to help there. I was thinking that perphaps sysconfig could help me get my helloworld.py application into a \Program Files\hello world directory and everything would be rosy. But not yet. So I will wait. > Distutils isn't perfect but solves the need of installing public > modules and packages quite well. If you say so - but compared to what ? CPAN? :-) Have a nice day David ___ 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
Re: [Python-Dev] First draft of "sysconfig"
On Wed, 16 Dec 2009 21:21:01 +1000, Nick Coghlan wrote: > .. we mostly leave that to the py2exe/py2app + native installer > developers of the world. There are a *lot* of thorny issues in getting > installers fully in accordance with OS developer guidelines, which is > why we tend to shy away from it. And that is fair enough. In the commercial world, once the python gets compiled, you're mostly talking about some application where the source code needs protection. The bar is raised - to match the available budgets. However, I would like to point out a category of applications that live in source code form. Inside scientific or commercial organisations. These are apps that are never compiled - and just run in interpreted mode. Maybe they're on workstations, or maybe they're on web servers. It doesn't matter that much. The point is that the python Configurations exist over many machines. What I'd like to suggest is that python apps are becoming more network centric. To the point where it might at some time in the future it might well become a 'python-core' issue. I'm not suggesting writing a new SCM because so many already exist. And in python too - haha - how great is that. All that I'm doing is suggesting that the python of the future and the stdlib of the future will include celery or superpy or the mercurial or bzr interfaces, and it will be really easy to roll out the 'helloworld.py' app/web-app out to the desktop machines or django server or cluster or cloud of machines wherever they actually are. The machines will just have 'python' installed, and then from there everything will pretty easily take place (apps/packages get pushed to remote machines). I'm not star-gazing, because all these things are already needed and already being done to some degree in some organisations. There's already the libraries on pypi for most of this anyway. The practical advantages of some of us going in this direction is that it might be possible for us open sourcers to attract the attention of our commercial sponsors attention. Because they're always interested in getting new toys and utilising their resources in the most efficient way. If we do the above, incorporate tested packages from pypi, it's possible that the glow of CPAN might be tarnished somewhat. David ___ 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
Re: [Python-Dev] First draft of "sysconfig"
On Thu, 17 Dec 2009 12:18:00 +0900, "Stephen J. Turnbull" wrote: > > .. because all these things are already > > needed and already being done to some degree in some > > organisations. There's already the libraries on pypi for > > most of this anyway. > > ... > There clearly is no interest in going down the > road you propose. Hmm.. well.. projects like buildout, superpy and celery suggest that people are already working and thinking this way. Lots of companies use clusters of python computers and these needs will only increase over time. If it's only +1 from one person to make python more network centric with sysconfig in 2010, then so be it. Have a nice day. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Martin, As an application developer, I really stand with Tarek here. On Wed, 23 Dec 2009 20:07:30 +0100, Tarek Ziadé wrote: > 2009/12/23 "Martin v. Löwis" : >>> I think we want something stronger than that since they were not really >>> used by >>> the community and removed and replaced by something better. Using them >>> should raise a warning so developers abandon them, so it would be >>> "don't use 1.1 anymore" Yes. But that is a software warning message to be implemented within the installation software. The important thing is what is in the metadata. > I am just describing the needs and the end user PoV with the reference > implementation that happens to be used by *all* tools out there. That's good. That's what we need right now. > So that will happen in the code of course, but we need the PEP to state > clearly > wether metadata 1.0 and 1.1 should be dropped by implementations or not. +1 >> It would be also incompatible with existing consumers that expect >> a Python package to have an earlier version of the metadata. >> Dropping 1.0 may be fine though - but again, this is out of scope >> here. That's a software implementation issue. Not a metadata issue. > I don't understand why you are saying this is out of scope. Shouldn't we > state clearly in the PEP that 1.0 and 1.1 should not be used in the future I agree with you Tarek. Whilst we can suggest that the implementation be done in certain ways. The PEP in it's current form seems good enough an I am hoping it will go through soon. Three more years of deliberation and niggling on this PEP will have more of an adverse affect than a positive effect. It was started in 2005 and that seems like a long time to hold things up. There's always time for a 1.3 version in two years time if there is an unstoppable problem here - but I can't see any. As an application developer, I have to side with Tarek. Lets get this finalised. Thank you David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" wrote: > Martin's point is that the PEP process doesn't *have* "reference" > implementations. It has *sample* implementations. It may be useful > to refer to a sample implementation as an example.. Fair enough. But otoh, asking for sample implementations on this type of project can skew the PEP towards a particular implementation or product. A definition for metadata should be something quite abstract and self contained. So imo I am happier where it is currently. > What implementations do is another matter. Right. We all agree on that. > An implementation with lots of state like PyPI is not likely > to change quickly. As a matter of user relations (including but not > limited to developers like you), Python doesn't want to deprecate > practices that are expensive to change too soon. (That's not my > opinion about what is appropriate, that is my assessment of the > historical policy of Python, which I don't think will change.) Well I would need more convincing that it is better to do one PEP every 4-5 years as a user relations exercise than one PEP every year or two years. Whilst I agree that the core language is really great and the rate of progress can happily slow. It would be nice to see the rate of progress of other areas, such as the metadata side, increase a little. That wouldn't break policy David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan wrote: >> Martin v. Löwis wrote: > FYI we have introduced a range operator, so one may define a range of > versions. > This is useful for instance to write: > > Requires-Python: ~=2.5 > > Which means: requires any version of Python 2.5.x. This operator is > the default operator, > meaning that you can also write: > > Requires-Python: 2.5 I don't like the ~ at all sorry. The ~ operator is thoroughly confusing. No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly. Before we had : Requires-Python: 2.5, 2.6 That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios. I hope we can go back to the original proposal. :-) David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
>> No application developer will quickly figure out what a tilde means. >> Maybe >> it means 'roughly', but it requires too much thought and is ambiguous. >> 2.5 >> is not roughly 2.5.2. It is the same exactly. >> >> Before we had : Requires-Python: 2.5, 2.6 >> >> That made much more sense. It was simple and unambiguous, and is >> relevant >> to typical packaging scenarios. > > Unfortunately, it is fairly ambiguous, and makes no sense. It means > "requires Python 2.5 *AND* requires Python 2.6", which is a requirement > that no single version can meet. No, it means a library requires either python 2.5 *OR* python 2.6 to be installed properly. If not, the implication is that the user will be prompted to install anyway. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> Instead, the default should be â==â. That is, âRequires-Python: 3â > should be equivalent to âRequires-Python: ==3â; and only â3â or > â3.0â or > â3.0.0â etc. will match. I maintain that is what most people will > expect > on seeing that syntax. > > If a less strict range is desired, the existing comparison operators > â>â, â>=â, â<â, â<=â are sufficient, more obvious, and > more explicit. In > other words, to get the meaning you desire above, the existing operators > can be used: âRequires-Python: >=3, <4â. Yes, so that: Requires-Python: 1,2,3 means python versions 1,2 or 3. Requires-Python: 3 means requires python 3 only. Any version of 3 Whereas: Requires-Python: 3.0, 3.1 means only 3.0 and 3.1 Requires-Python: 2.3, 2.4, 2.5, 2.6 That means, those particular versions. A user can still try to install on other versions. But they would get a warning and would do so at their own risk. There's no need for extra operator characters as far as I can see. The comma method proposed originally seemed to do everything. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
>> Tarek Ziadé gmail.com> writes: > An implicit range operator is simpler indeed, and achieves the same goal. > > Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well. With respect, it's not a very common use case for a developer to say that package needs a python interpretor 'older' than 2.5. There comes a point where you can just not expect a python interpretor, say 1.3, to not work with your package. So they wouldn't say that. I don't think. Nor would they say it going forward. So ">=2.5" might be too bold a claim for them to make. As they might not have tested on the 'latest-and-greatest' interpretor. That would imply that they know it works on all 3 series interpretors. imho, all that they would know, is that they're using python (for example) 2.4 or 2.5 (pick a python version) and they know it works pretty well. It's then up to the user if they want to use it on any other version. That's why I don't think we need the '=' '>=' operator characters to represent typical use cases. If there's any use-case, that I have missed. Do let me know. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> david.l...@preisshare.net writes: > > > With respect, it's not a very common use case for a developer to > > say that package needs a python interpretor 'older' than 2.5. > > Of course it is. I don't claim it is the majority of cases out there, > but stable versions of many of the packages I use will specify an > older python (Mailman and Zope both specify a range of Pythons, rarely > including the most recent release, and Bazaar, although it tries to > keep up with Python releases, tends to recommend being conservative, > sticking to release (n-1) for the first few months into release n.) > > And in fact this case is often more the important one. Packages that > depend on having a *recent* version of python will often crash > quickly, before doing permanent damage, when an undefined syntax, > function, or method is invoked, while packages that depend on a quirk > in behavior of an older version will typically silently corrupt data. > > > imho, all that they would know, is that they're using python > > (for example) 2.4 or 2.5 (pick a python version) and they > > know it works pretty well. > > If they want to specify a Python version that works, they may as well > bundle it, and many do. But even in that case the user may want to > know about the dependency. > > BTW, *all* of the Python applications I really care about make a point > of specifying a range of versions they work with (or bundle a > particular version). So in fact many developers do know what versions > work or fail, and often why (and they sometimes even provide > workarounds/patches for adventurers who want to use a Python outside > of the recommended range). > > > It's then up to the user if they want to use it on any other > > version. > > This is often an undesirable posture. From the user's point of view, > the system version of Python may have passed various local tests and > therefore be strongly preferred (for example, requiring far less time > for approval from the security team). This is especially true for > mail or web applications and other applications that must run in a > very hostile environment. Many developers do want to provide this > kind of information to such users. > > I think you should rethink your position on how valid your personal > intuitions are for generalization. You are certainly representative > of a certain important segment of developers, but I don't think you > have a good sense of the very broad class of requirements that other > developers are bringing to the table. > ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Hi Stephen, > BTW, *all* of the Python applications I really care about make a point > of specifying a range of versions they work with (or bundle a > particular version). Yes, well that was my point exactly. If opinion is against commas, then we can take them out. That would give us something like: Requires-python: 2.5 2.6 2.7 3 That would specify a bundle of versions. Processing that only requires the string split() function. If we were to adds Lens suggestion of the range indicator that would simplify things even more. Requires-python: 2.5:2.7 3 That would specify everything between 2.5 and 2.7 and then everything in the 3 series. This would make it very simple. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Hi Len, > Another penny dropped when it comes to version specs. Pennies are good. They build value. > With examples being: > > Requires-Python: [2.5.2:3]; [3.1:] What about going even more simple... Requires-Python: 2.5..3 3.1.. If we use double-dots to replace colons, the .. will translate to 'to'. So taking your example more closely might be: Requires-Python: [2.5]..[2.7]; [3.1].. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis" wrote: > On distutils-sig, a vocal fraction seems to think otherwise. From my > short interaction there, I now think that comparison operators are > indeed hard to use, and that the concept of a half-open interval, > and how you can use relational operators involving the endpoints > to denote it, is (apparently) *quite* advanced. Absolutely. From Len and my interactions, I will wrap up and make one addition to the set. I'm adding one last proposition. > Requires-Python: 3 Requires a particular python version. > Requires-Python: 2.5:2.7 Specifies a range of python versions. > Requires-Python: 2.4+ Specifies anything above a particular python version. (No need to ask me about a less than operator. I think a packager would feel more comfortable with using the range operator than a 'less-than' operator. There just comes a point where people don't bother with old interpreter versions) That wraps it up for the vocal faction... Happy new year David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, 28 Dec 2009 23:07:32 +, Michael Foord wrote: >>> Requires-Python: 2.5:2.7 >> >> Specifies a range of python versions. >> > So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 > implicitly mean a range of all Python 2.7 versions? Yes. 2.7 would mean all 2.7 versions. As 2.7.1 is a 2.7 release. > If not how do we specify up to the last version of 2.6 (which may not > yet be released) but *not* 2.7? > > 2.5:2.6.9 ? No. As you might never know what the last release may ever be as they keep on coming. So like this: > Requires-Python: 2.5:2.6 That will catch all 2.6 unreleased versions (security fixes et la) and not 2.7 David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, 28 Dec 2009 23:21:54 + (UTC), Antoine Pitrou wrote: >> > Requires-Python: 2.5:2.7 > > Why not drop ranges as well as operators and simply use commas? > The above would be rewritten as: > > Requires-Python: 2.5, 2.6, 2.7 Firstly, I find your notation proposition to be entirely workable and rational. Len threw in the range notation as a kind of novel idea, but the more I use it, the more that I think it is applicable in this use case. Packages and the interpretor version is about ranges. The choice (for the packager) comes down to either one particular python version (2, 2.x, or 3, or 3.x), or a range of python versions, or a set. There's no reason that I can see why we could not have both, that is a set and a range as Len has suggested. Whether the delineation is with commas or spaces is, to me, is minor. > You might argue that if you want to include 8 versions > of Python this makes the notation slightly longer, but > who tests their package with 8 different versions > of Python? You're right. The set notation is more obtuse. But with your notation, I hope there would be no problem. For instance: > Requires-Python: 2, 3 To me that would cover all 8 versions. As for the testing thing, well that's the cpan debate.. another thread. > (and if you don't test exhaustively, just use the "2.5+" notation) Exactly. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray" wrote: > What about specifying that the package works only with, say, 2.6.2 or > earlier (because of some problem introduced by 2.6.3)? That could get > pretty darn verbose. (Also remember we aren't just talking about the > syntax for Python versions, but versions for any package). That's why the range operator could be good. > Requires-python: 2.4:2.6.2 > I do think it is also a valid argument that, from what I've heard here, > most extant (linux at least) packaging systems use the >=, etc, operators, > so I think talking about changing the proposed syntax radically is > probably misplaced. The counter argument for 'cloning' the linux packaging system is that most of the representations come from a C perspective. Because of the fact that Linux is predominantly a C product. Since Python isn't C, and doesn't come from C, then one could argue that using short-hand or high level notation is more in keeping with the character of python. So the arguments against the >= == operators come from the desire to keep what looks like C code, *out-of* python packaging. I fully sympathise that some have the desire simply to clone what's already out there. Why make new art when there's a lot of old art already.. The price of doing that is we lose the specific short-handed high-level nature of python. Which is what we were attracted to in the first place. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Tue, 29 Dec 2009 12:00:50 +1100, Ben Finney wrote: > The dependency declarations are *not* Python language syntax, and there > is no need to consider Python language syntax in defining them. Well I don't know how you can say that if it is python developers to which all this effort is targeted. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> On Mon, Dec 28, 2009 at 1:15 AM, Tarek Ziade wrote: > > This new operator removes the ambiguity the original proposal had, > without making it more > complex for common use cases. So if you dislike it, you will need to > propose something > else that also fixes the ambiguity we had. Ok. > Environment markers >.. >Here are some example of fields using such markers: > >Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' Requires-Dist: [Windows] pywin32 1.0+ That's simpler, shorter, and less ambiguous. Easier to parse for package managers. David ___ 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
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Hi Martin, Happy New Year, >>> Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' >> >> Requires-Dist: [Windows] pywin32 1.0+ >> >> That's simpler, shorter, and less ambiguous. Easier to >> parse for package managers. > > Don't you want the PEP to complete? Why this bike-shedding? Well, I'm just helping out by pointing out some simpler ways as Tarek asked me. I was only answering his question. I was out celebrating so it took longer to reply than normal. Bike-Shedding ? Me ? which bikeshed? wanting simple? Anyway, I'm just reading the PEPs and commenting. If there are some alterations that can be done, lets discuss them. > I can agree it's shorter. > .. Cool. What I'd really like is a 'Code-Repository:' keyword so that we can install programs/libraries directly into a system. I feel that this would really simplify the packaging landscape, making it much easier for the scientific community and others to do python software installs. This would allow us to perphaps have something even *more modern* than CPAN. So yes, getting PEP-345 right is important to me. Have a nice day. David ___ 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
Re: [Python-Dev] Suggestion: new 3 release with backwards compatibility
Hi Martin, > ... but in the long run, starting now will have saved you a lot of > pressure in the long run, and stop users from switching away from > your packages because of lack of Python 3 support. In a production situation it works the other way around. If there's an application that requires twisted (or whatever package) then most people would use the appropriate interpreter to match the library. Since you guys all did your jobs so well :-) doing so is painless. Because there is so much "comfort" with the existing situation it makes it an effort for people to move to a different lounge chair. Namely python 3. I'd suggest that moving the package set (pypi) to python 3 could be kicked along with the help of some automated tools. I don't know what tools you guys have got. But I am very sure that if code analysis was provided to package developers on python 3 (so they don't have to run it themselves), then it would be like an even bigger tv screen in a bigger lounge room and it would assist in drawing them over. David ___ 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
Re: [Python-Dev] Suggestion: new 3 release with backwards compatibility
Hi Ian, > The only workable workflow I've seen people propose for maintaining a > single > codebase with compatibility across both 2 and 3 is to use such tricks, > with > aliases to suppress some 2to3 updates when they are inappropriate, so that > you can run 2to3 on install and have a single canonical Python 2 source. > Python 2.7 won't help much (even though it is trying) as the introduction > of non-ambiguous constructions like b"" aren't compatible with previous > versions of Python and so can't be used in many libraries (support at > least > back to Python 2.5 is the norm for most libraries, I think). > > Also, running 2to3 on installation is kind of annoying, as you get source > that isn't itself the canonical source, so to fix bugs you have to look at > the installed source and trace it back to the bug in the original source. > > I suspect a reasonable workflow might be possible with hg and maybe patch > queues, but I don't feel familiar enough with those tools to map that out. That's why I am saying that we need a Code-Repository: section in PEP-345 Metadata. Let package developers keep two branches in SCM. One for 2.x and one for 3.x Let them backport features from their 3.x development series to their 2.x code base. In exactly the same way that it is done in so many other developments today. Keeping multiple branches of code is a very common thing these days. And there are tools in the outside world (bzr,svn,mercurial) that allow us to do it very easily. Let's have that support in python; it will make life easier. David ___ 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
Re: [Python-Dev] PEP 386 and PEP 345
> Hi, > > I think we've reached a consensus on those two PEPs. > > Although, there's one last point that was forgotten in the discussions > : I've introduced "rc" in the pre-releases markers, so PEP 386 is > compatible with Python's own version scheme. "rc" comes right after > "c" in the sorting. It's slightly redundant with the "c" marker but I > don't think this really matters as long as consumers know how to order > them (a < b < c < rc). I have also stated that "c" is the preferred > marker for third party projects, from PEP 386 point of view. > > Is there anything else I can do to make those two PEPs accepted ? Tarek, Given that I helped out so much last year with the PEP in discussing different options, even if they weren't accepted, I really feel that it is unfair if my name isn't mentioned. It was a huge time sacrifice on my part. For example, even if I only managed to explain the version numbering and clarify how that worked. It did take me some time to do that. What I did do however, was spend a lot of time with the multiplatform "Markers". I still think that two short weeks more of "discussion" could resolve some issues. That discussion went for 4 months on distutils-ml. Look, major issues aside, can you make the following concessions on PEP-345 which I only feel will help it, namely: 1) Source-Repository: specify a code repository to install from 2) Streamline Requires-Python: by implementing "Markers" as noted by the PEP. A marker being something like "Requires-Python(windows): lxml". Otherwise remove the word marker from the PEP and just replace with "metacode". Markers are what were discussed on distutils-ml. Metacode is what is described in the PEP. 3) Remove the inconsistency and platform ambiguities. Especially for windows users. For example, "win32" is extremely confusing for windows users right now. As more and more systems now are 64 bit. Use the platform module, instead of the sys module for constants. I'll post to distutils-ml on this. I am certainly not trying to hold this PEP up, and I apologise on my part for my late attention. I will post to distutils-ml on these and i promise to keep my comments unheated and unwitty. Having said that, PEP-345 is *super-important*. A week or two or three more discussion and the issues can be resolved. We all just want to focus on being productive. It would be a great accomplishment for you to get PEP-345 approved and likewise for me getting mentioned even in a minor role as helping out on a PEP. So I'm hoping that you can make a few last minute concessions meaning that we can all happily go on our way in 2010. Regards David ___ 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
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
Hi Martin, > Of course, the less active fraction of Python contributors may not > notice, since they just chose to not contribute (which, of course, > is fine). However, asking me to work twice as much as I want to > on the project to keep two branches alive is just unfair. Totally true. Actually as an end-developer I'd say that python 2.x series from a programming perspective is quite good. It doesn't need the addition of a lot of new features imho. So for me, I think too much time spent there would be not yield great benefits. > This has nothing to do with pushing 3.x, but all with managing > available manpower and still providing quality software. Well, we all know your work is super quality. :-) That's not being contested. However, Quality can be measured different ways and it can be assessed in different ways. Quality itself is a subjective thing. The point I'm only making is that if a piece of software doesn't have "new" things added over time, then users can get a reverse impression of a lack of quality. We've all seen where 'internal' quality can increase and user perceptions can decrease. It could be things like improved graphics and things readily apparent to the user. At the moment, I would say that the "internal" quality of the python 2.x series is super high. "external" quality issues such as the packaging dilemma give the user the opposite quality experience. But people are working on that as best they can elsewhere. I'll leave it at that. > This has nothing to do with pushing 3.x, but all with managing > available manpower and still providing quality software. Python 3.x needs more carrots. >From an ordinary (perphaps ignorant) user perspective there is nothing. Yes, we know if we actually will start programming then we will like it more. But my wishes to Santa Claus would be allow the free flow of PEPs for Python 3 packaging. Even encourage it. As an end developer, here's what I'd like from Santa in 2010 to get me to swap to python 3: * get all the packages on pypi tested for python 3 * put a web based package manager in python 3. This would perhaps be based around PIP (keep many people happy) and would look much like the built in web-console that you get with a $200 router. * Incorporate SCM based end-user software installs by adding to python3-stdlib the SCM support packages (cvs,bzr,svn,hg). This would *really* help in the scientific community. * put a web interface on distutils also so that we don't have to use a command line interface. (I want a pic of a smiley girl to great me when I build something - "Are you ready to build now Honey?"). ok - I joke. But the point is made. So, ok, maybe these things aren't about 'code' quality. But rather user experience. Things like these do count also as "quality" via the technical term "perception of quality". If the PEP process is as unblocked as the documentation implies, implying that anybody can contribute to Python 3. Then there shouldn't be any issue. David ___ 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
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
Antoine writes: > As someone who experiences the difference almost every day, I can say 3.x > definitely has enough carrots for me. The simple fact that I will be able > to > raise exceptions with non-ASCII error messages without having to > workaround a > hopelessly broken conversion/reporting logic is a huge improvement. And > that's > only a small part of the picture. In no way could I disagree with you. Ascii works fine for us here - but I guess we're lucky. Just keep pushing python 3 and have a nice day.. David ___ 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
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
> Nick wrote: >>> This has nothing to do with pushing 3.x, but all with managing >>> available manpower and still providing quality software. >> >> Python 3.x needs more carrots. > > As Guido has said a few times, the gains are far greater for *new* > Python developers than they are for existing ones. Well both you and Guido are most likely 100% correct. :-) > They don't have as rich a 3rd party ecosystem > on Python 3 as they would on Python 2.x at this point in time, but > unlike existing developers they also have the luxury of cherry-picking > just those packages that already have Python 3 support. Most likely. I wouldn't want to say anything to discourage people from going to python 3. In other languages, I have much experience of making the jump to 'a whole new world'. It's unsettling at first, but after that, you suddenly find the new model has a better turbo than the last and you're at the next corner faster than you can think. So it's all good. But I still maintain Python 3.0 needs more carrots. For example, if mercurial or any other cool lib gets added to python 3 (and I can name a few that should go in python 3) then they should be added to python 3 and not to python 2.x They would serve as good carrots. Make fresh the python 3 stdlib and preserve the python 2.x stdlib. I really think we are somewhat short on resources to do what Guido has asked about bringing python up to CPAN level with respect to packages. We're starting a long way back with horses and swords and trying to catch a well fed and greased modern machine.. I'm sure we can get a modern package testbot operational for python. But I wish those who were complaining about the packaging problem so much could throw some money at the problem instead of moaning about it. As is done on other open-source projects. Some organisation would be beneficial. Finding funds so that a small group of people could work on the problem would be a great boost to forward progress. I just think python packaging needs six months of that to repair the years and years of neglect and stagnation. Even if it is only beer and bus fare money. It just needs a temporary shot of adrenalin in the arm.. so to speak.. Regards David ___ 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
Re: [Python-Dev] PyCon Keynote
On Wed, 13 Jan 2010 10:51:14 -0800, Guido van Rossum wrote: > Please mail me topics you'd like to hear me talk about in my keynote > at PyCon this year. As a typical (but perphaps more vocal) python developer I would like to hear things that might aspire me and others to move to python 3. The way I see it is that python 2.x represents everyones comfort zone. It's safe and nobody got fired at work for using python 2.x I would like to hear how python 3 could be 'shaken' up with a slightly less conservative policy that has gone with the python 2.x series. The logic perhaps being that since only a minority use the 3.x series, it's functionality set is still more up in the air. imo it needs bigger batteries to give it more power than the 2.x series. This meaning that the stdlib could take an extra 5-10 packages not in the 2.x series. Just as one example, sphinx - a great documentation tool. I can easily name five or six others. I'd also like to hear more of your ideas on pypi and getting it to have as much who-ha as CPAN. You could do a lot to enlarge the developer group. Help us all get our priorities to be inline with your own wishes and expectations. If you ask us all to put in a big year and buy you a beer at the end.. I'm certain we all will. Every little bit of inspiration and direction counts for a lot... Best Regards David ___ 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
Re: [Python-Dev] Bazaar branches available (again) on Launchpad
Hi Barry, That looks very interesting... So does that mean we could update the stdlib for a given python version using this ? David > I've just updated the Launchpad mirrors for the 4 active Python branches, > trunk, py3k, 2.6, and 3.1. These used to mirror the defunct Bazaar > branches > on code.python.org but it's probably been 7 months or so since those were > regularly updated. Now the Launchpad branches sync against the read-only > Subversion branches at http://svn.python.org, so they should remain > up-to-date > (within the re-sync timeframe of about 4 hours). > > This means you can once again use Bazaar to get local branches of Python, > and > you can of course push your own branches to Launchpad. I believe you can > even > use the bzr-svn plugin to commit changes back to the Subversion master, > though > I have not yet tried this. > > To get a local branch, just do any of the following: > > % bzr branch lp:python (for trunk) > % bzr branch lp:python/2.6 > % bzr branch lp:python/py3k > % bzr branch lp:python/3.1 > > (It's fairly easy to create new mirrors for other Subversion branches, > e.g. Python 2.5; just drop me an email if you want them.) > > If you're going to create a lot of branches you probably want to put them > in a > shared repository. E.g. > > % bzr init-repo pythonbzr > % cd pythonbzr > % bzr branch lp:python/py3k > > Bazaar 2.0 or better is recommended. For me, it took about 5m to check > the > first branch out from Launchpad, and then about 30s or so for each > subsequent > branch. > > Enjoy, > -Barry > ___ > 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/david.lyon%40pythontest.org > ___ 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
Re: [Python-Dev] Bazaar branches available (again) on Launchpad
> On Jan 20, 2010, at 10:16 AM, Barry wrote: >> So does that mean we could update the stdlib for a given >> python version using this ? > > In a sense, yes (if I understand your question correctly). Yeah, it just needs an implementation. > The one thing I am unsure about, mostly because I have not tried it, is > whether your Bazaar branch can be used to commit directly back to the > Python Subversion master branches. I /think/ the answer is yes, > assuming of course that you have permission to do so... Well I'm too Senior and my stuff is too forward looking to qualify for that just yet. I'd be happy to see bzr and mercurial and git all made it together into the stdlib for python 3. That would give a superb updating mechanism for python that would propel python well beyond the dinosaur badlands of CPAN and other languages. I was actually reading from (http://en.wikipedia.org/wiki/Python_%28programming_language%29): "Rather than requiring all desired functionality to be built into the language's core, Python was designed to be highly extensible. .. .. This design of a small core language with a large standard library and an easily extensible interpreter was intended by Van Rossum from the very start because of his frustrations with ABC (which espoused the opposite mindset).[5]" To me, the source code control systems seem to be fully in tune with the original design of python. That is, to be able to easily pull external libraries in. I think what has changed is that the mechanisms now (the SCMs) are way more highly developed than before. Apart from that though, after reading the full wikipedia article I'm left with the distinct impression that things are still pretty much the same (in that python design philosophy is advanced), just that the landscape (of external C libraries) has changed. Now all the libraries are external (on the internet) and all externally managed. So with just a tiny amount of work, imho we could pull it all together to bring python 3 *back* to being that cool tool that it once was (not saying it isn't now). Were you offering me an experimental branch somewhere for python 3 SCM integration ? David ___ 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
Re: [Python-Dev] Bazaar branches available (again) on Launchpad
> On Tue, Jan 19, 2010 at 7:51 PM, Jesse Noller wrote: > Python 3 is still modularized, still has a standard library, etc. If > you're really interested in helping with the standard library, get on > stdlib-sig, and get ready to write code and PEPs. Thank you for your direction to move these items forward to PEPs and Code. > i sincerely doubt that a source control system will be included in the > standard library in the future. Especially 3. Yeah and who twenty years ago thought you would get a 1GB memory card for $3 when all we had was 10Meg hard disks and they were the full 8" platter. > A SCM is not a "package management system". Exactly. It almost makes the need for a "package management system" pretty much obsolete if you can update your code directly from the developers sources. That's what all these SCMs provide. Plus it's addictive. It's hard to go back to 'package' style technology once you have all your code on an SCM based feed. > Barry was talking about mirrors of the python code. It is true a > "package manager" could be developed based on a SCM, however you need > to implement this far away from the stdlib and get traction with it > within the community long before inclusion would be considered. I think I'll have better chances with PEPs. Being honest, if wonderful libraries like Sphinx and Mercurial and Git and BZR can't make it into the stdlib, then there is no hope for even newer code to get in there. Plus, promoting all sorts of new and fangled tools however good they may or may not be just confuses users and ends up being a waste of time imho. It isn't good management of volounteers time and effort. If you could imagine disaster relief coordinated this way, it would just be a disaster in itself. That's why it has taken some 5 years to get PEP-345 done. > The decision to move python's source control from SVN to mercurial was > controversial enough; including 3 or more scm libraries into core > would be an intractable uphill mountain of bike sheds. Not at all. It would be a very fair thing to do. Not to mention being great for users. > Barry made bzr mirrors of the python svn tree. Not a python with bzr > included. I can't resist asking for that again.. I heard it only in Monty speek. Did you just say ?: "Barry made a bizarre mirror of the python suvern tree. Not a python with a buzzer included." Anyway.. Maybe I do get what your talking about. Even if you do talk with a strange accent. :-) David ___ 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
Re: [Python-Dev] Bazaar branches available (again) on Launchpad
> On Jan 19, 2010, at 08:09 PM, Barry Warsaw wrote: > > I'd be surprised if any of the big 3 DVCS developers would actually /want/ > their stuff in the stdlib. If they ask, they'll get told they're motorbike-shedding. "It's better if their users ask". So here I am as a user doing things the 'right' way. > Being in the stdlib has its advantages and > disadvantages. I think for rapidly developing technology, the > latter can actually outweigh the former. If it's about being able to do updates, then I think this resolves an old and circular argument. As the SCM implementation would, one would expect, to be able to update itself. Side benefits are that it can update everything else along with it at the same time. User Apps, Packages, whatever. It's even better having SCM in an Industrial/Scientific environment. Here's an example: - a machine breaks.. (I mean the software for/in it) - you fix the code, maybe on the spot - you commit and push back to the repository - your code gets checked in and run through the testbot and then you get blamed and have to do the whole thing again properly with a test case. Oh well.. Well anyway, whatever you guys might say, that's a whole lot more efficient than running back to the development machine and going through some obscure build and test and publish process to do a fix on a production machine. Point : The fact that SCMs are two way is great in a production environment. No packaging solution can come close. So why not have python SCMs included as batteries in python.. All these arguments I can take off to the stdlib list when I get the chance.. David ___ 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
Re: [Python-Dev] Bazaar branches available (again) on Launchpad
> "David Lyon" writes: > >> Being honest, if wonderful libraries like Sphinx and Mercurial and Git >> and BZR can't make it into the stdlib, then there is no hope for even >> newer code to get in there. > > Those are applications, not libraries. Applications don't belong in the > standard library. Haha funny.. Well using that logic, distutils is an application.. Are you saying that distutils should be removed? That is most certainly an application. Lets not get too pedantic here. Mercurial and bzr have a built in API that can be called in a library like way. It's true they also have a command line interface in the same way that distutils does. I'm not saying anything negative about distutils. Given that Tarek has an upcoming Pycon presentation where the program talks about a distutils revamp. I'm hoping that he can find some young 20 yr olds and put a cool web interface on that thing. Given that there are empty sprints at pycon. It couldn't hurt to throw that challenge out. Anyway, we'll see.. David ___ 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
Re: [Python-Dev] Bazaar branches available (again) on Launchpad
Matthieu, >> I'd be happy to see bzr and mercurial and git all made it together >> into the stdlib for python 3. That would give a superb updating >> mechanism for python that would propel python well beyond >> the dinosaur badlands of CPAN and other languages. > > I think there are several points that make them not includable in Python: > - git is not written in Python > - bzr and mercurial have a life cycle much shorter than Python's, it's > the same issue than with other libraries where another community > develops them. That's only two points. :-) On 1; If that's true, I won't mention git again. On 2; Who knows what their life cycle is. CVS is pretty much dead, and svn looks like it is on the way out. I can't think of how anything could be better than mercurial or bzr but I know I will be proved wrong. At the end of the day, we are making a decision about whether the language is 'set-in-stone' or whether it is still evolving. To me, Python 1.x had it's own distinct "era", as has Python 2.x Hoping that the Python 3 era can be a little more flexible and perphaps "cleaner" than the 2.x era is all that I am thinking here. Have a nice day David ___ 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
