Mailman 3 October 2009 - Distutils-SIG

[issue87] [PATCH] Python 3 support
by Phillip J. Eby 10 Oct '09

10 Oct '09

New submission from Phillip J. Eby <pje(a)telecommunity.com>: Copy of issue 56; see file 35 for patch ---------- messages: 378 nosy: lregebro, pje, pjenvey priority: wish status: chatting title: [PATCH] Python 3 support _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue87> _______________________________________________

1 0

[issue86] [PATCH] python setup.py test in python2.6
by Phillip J. Eby 10 Oct '09

10 Oct '09

New submission from Phillip J. Eby <pje(a)telecommunity.com>: Copy of issue 56 ---------- messages: 374 nosy: lregebro, pje, pjenvey priority: bug status: chatting title: [PATCH] python setup.py test in python2.6 _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue86> _______________________________________________

1 0

Re: [Distutils] [Python-Dev] Bits-of-Distribute naming
by Floris Bruynooghe 09 Oct '09

09 Oct '09

On Fri, Oct 09, 2009 at 06:05:50PM +0200, Tarek Ziadé wrote: > On Fri, Oct 9, 2009 at 5:42 PM, Chris Withers <chris(a)simplistix.co.uk> wrote: > > Tarek Ziadé wrote: > >> > >> - The code is splitted in many packages and might be distributed under > >> several distributions. > >> > >> - distribute.resources: that's the old pkg_resources... > > > Why not just call it pkg_resources and/or merge it with pkgutil to get it > > into the python stdlib? > > Because "pkg_resources" belongs to 0.6 and we want 0.7 to be > installable alongside 0.6 if needed. [...] > > Why not call in "pypi.client" and "pypi.server" or, better yet, get it into > > the stdlib as disutils.index.client distutils.index.server? > > We are keeping a "distribute." namespace for all bits. > > Now maybe one day it'll make it into Distutils, yes. But not now. If the final plan is (or might be) to move distribute.resources into the stdlib might it not ease transition to pick an import name that will be able to remain the same? Regards Floris PS: Moved discussion from python-dev to distutils-sig, hope that's fine. -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

1 0

Re: [Distutils] [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by Ian Bicking 09 Oct '09

09 Oct '09

Probably all these discussions are better on distutils-sig (just copying python-dev to note the movement of the discussion) On Fri, Oct 9, 2009 at 11:49 AM, Michael Foord <fuzzyman(a)voidspace.org.uk> wrote: >> Outside of binaries on Windows, I'm still unsure if installing eggs >> serves a useful purpose. I'm not sure if eggs are any better than >> wininst binaries either...? > > Many Windows users would be quite happy if the standard mechanism for > installing non-source distributions on Windows was via the wininst binaries. > > 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. As far as pip works, it unpacks a package and runs "python setup.py install (and some options that aren't that interesting, but are provided specifically by setuptools)". Well, it's slightly more complicated, but more to the point it doesn't install in-process or dictate how setup.py works, except that it takes some specific options. Running a Windows installer in the same way would be fine, in that sense. Alternately pip could unpack the wininst zip file and install it directly; I'm not sure if that would be better or worse? If wininst uses the central package manager of the OS then certain features (like virtualenv, PYTHONHOME, --prefix, etc) would not be possible. For Distribute (or Setuptools or by association pip) to see that a package is installed, it must have the appropriate metadata. For Setuptools (and Distribute 0.6) this is a directory or file, on sys.path, "Package.egg-info" (or in Package-X.Y.egg/EGG-INFO). If a file, it should be a PKG-INFO file, if a directory it should contain a PKG-INFO file. So however the package gets installed, if that metadata is installed then it can be queried. I don't think querying the Windows system package management would be necessary or desirable. Nobody is trying that with deb/rpm either. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker

1 0

Re: [Distutils] [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by kiorky 09 Oct '09

09 Oct '09

I'm crossposting to continue on distutils. Ian Bicking a écrit : > On Fri, Oct 9, 2009 at 3:54 AM, kiorky <kiorky(a)cryptelium.net> wrote: > Well, if multi-versioned installs were deprecated, it would not be > necessary to use Setuptools' style of script generation. Instead you > could simply dereference the entry point, calling the underlying > function directly in the script. This detail is probably more of a > distutils-sig question, and I don't have a strong opinion. > > But I was thinking specifically of the egg activation buildout puts at > the top of scripts. The egg activation is just the result of the constructed working set, which aggregates all the python packages that fulfill the options inputed by the user. The only needed packages and nothing else or more. >>> began development, probably things would have gone this way. I think >>> it would make the environment more pleasant for buildout users. Also >> * I don't think so, buildout is the only tool atm that permit to have really >> reproducible and isolated environments. Even, if you use the pip freezing >> machinery, it is not equivalent to buildout, Control! > > I believe that to fully insulate buildout you need still virtualenv > --no-site-packages. But I'm not arguing that virtualenv/pip makes Right, I do so, but i also drop nothing in that virtualenv site-packages. > buildout obsolete, only that they have overlapping functionality, and > I think buildout would benefit from making use of that overlap. recipes have more features and are another way to do, complementary or not. (patching, compiling options, pinning version). You have also more control on what is installed/used/shared with buildout than with the others. >> * Buildout can have single part to construct required eggs, at a specific >> version and let you control that. Pip will just search for this version, see >> that it's not available and fail. You have even recipes (like >> minitage.recipe.egg that permit to construct eggs with special version when you >> apply patches onto, thus, you can have the same egg in different flavors in the >> same eggs cache available for different projects. Those projects will just have >> to pin the right version to use, Control!. > > In my own work I use multiple virtualenv environments for this use > case, to similar effect. pip of course is not a generalized build > tool, but then minitage.recipe.egg is not the main egg installer > either. *.recipe.egg can use caches to avoid duplications among many projects environments. You setup seems to duplicate stuff around. >> * Another thing is the "funny script generation", you have not one global >> site-packages for your project, but one global cache. But from this global >> cache, your scripts will only have available the eggs you declared, see Control! >> * Moreover buildout is not only a python packages manager, it's some of its >> recipes that permit to use it as. Buildout is just a great deployment tool that >> allow to script and manage your project in a "funny" and "flexible" way, Control! > > Sure; I'm just advocating that buildout more explicitly use some of > the functionality of virtualenv/pip (which may require some more > features in those tools, but I'm open to that). But specific > discussion of this would probably be more appropriate on > distutils-sig. > -- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF

1 0

Re: [Distutils] [Python-Dev] excluding site-packages with buildout/virtualenv
by Chris Withers 09 Oct '09

09 Oct '09

[moved to disutils-sig] Ian Bicking wrote: > Well, if multi-versioned installs were deprecated, it would not be > necessary to use Setuptools' style of script generation. Instead you > could simply dereference the entry point, calling the underlying > function directly in the script. This detail is probably more of a > distutils-sig question, and I don't have a strong opinion. > > But I was thinking specifically of the egg activation buildout puts at > the top of scripts. Not sure what you mean by this last bit... > I believe that to fully insulate buildout you need still virtualenv > --no-site-packages. buildout has a --no-site-packages option (hopefully also specifiable in the [buildout] section) and some other cool things that I believe Gary Post worked on lurking on a branch waiting for Jim to review... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

[buildout] hard coded urls considered harmful
by Chris Withers 09 Oct '09

09 Oct '09

Hi All, bootstrap.py contains the following hard coded url: exec urllib2.urlopen('http://peak.telecommunity.com/dist/ez_setup.py' ).read() in ez With hindsight, this seems like a bad idea. For example, with the ridiculous situation we currently have with setuptools and distribute. It also means that the above url can't ever change, which is a bit of a harsh requirement. My suggestion would be for bootstrap.py to include the code in ez_setup.py, but that seems a little heavyweight. I guess this will all be solved when the standard library includes modules to download packages from PyPI and install them. But what to do in the meantime? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

3 5

ANN: ActivePython 2.6.3.7 (and PyPM) is now available
by Sridhar Ratnakumar 09 Oct '09

09 Oct '09

I'm happy to announce that ActivePython 2.6.3.7 is now available for download from: http://www.activestate.com/activepython/ This is a patch-level release that updates ActivePython to core Python 2.6.3 along with the fixes for a couple of critical regressions that instigated the work on 2.6.4. See the release notes for full details: http://docs.activestate.com/activepython/2.6/relnotes.html Introducing PyPM ---------------- This release includes a new packaging tool by activestate called Python Package Manager (PyPM). PyPM - currently in beta - is the package management utility for ActivePython. It simplifies the task of locating, installing, upgrading and removing Python modules. For full details, see: http://docs.activestate.com/activepython/2.6/pypm.html Here's a sample command line output:: $ pypm install lxml Get: [pypm.activestate.com] :repository-index: Ready to perform these actions: The following packages will be installed: lxml-2.2.2 Get: [pypm.activestate.com] lxml 2.2.2-1 Installing lxml-2.2.2 $ python >>> import lxml.etree >>>^D $ pypm remove lxml Ready to perform these actions: The following packages will be removed: lxml-2.2.2 Removing lxml-2.2.2 $ pypm install pylons Ready to perform these actions: The following packages will be installed: pastescript-1.7.3 formencode-1.2.2 weberror-0.10.1 simplejson-2.0.9 routes-1.11 nose-0.11.1 mako-0.2.5 past edeploy-1.3.3 pylons-0.9.7 tempita-0.4 webtest-1.2 beaker-1.4.2 webhelpers-0.6.4 paste-1.7.2 pygments-1.1.1 decorator-3.1.2 webob-0.9.6.1 Get: [pypm.activestate.com] formencode 1.2.2-1 Get: [pypm.activestate.com] nose 0.11.1-1 [...] Get: [pypm.activestate.com] decorator 3.1.2-1 Get: [pypm.activestate.com] webob 0.9.6.1-1 Installing formencode-1.2.2 Installing weberror-0.10.1 [...] Installing pygments-1.1.1 Fixing script /home/sridharr/.local/bin/pygmentize Installing decorator-3.1.2 What is ActivePython? --------------------- ActivePython is ActiveState's binary distribution of Python. Builds for Windows, Mac OS X, Linux, HP-UX and AIX are made freely available. ActivePython includes the Python core and the many core extensions: zlib and bzip2 for data compression, the Berkeley DB (bsddb) and SQLite (sqlite3) database libraries, OpenSSL bindings for HTTPS support, the Tix GUI widgets for Tkinter, ElementTree for XML processing, ctypes (on supported platforms) for low-level library access, and others. The Windows distribution ships with PyWin32 -- a suite of Windows tools developed by Mark Hammond, including bindings to the Win32 API and Windows COM. See this page for full details: http://docs.activestate.com/activepython/2.6/whatsincluded.html As well, ActivePython ships with a wealth of documentation for both new and experienced Python programmers. In addition to the core Python docs, ActivePython includes the "What's New in Python" series, "Dive into Python", the Python FAQs & HOWTOs, and the Python Enhancement Proposals (PEPs). An online version of the docs can be found here: http://docs.activestate.com/activepython/2.6/ We would welcome any and all feedback to: ActivePython-feedback(a)activestate.com Please file bugs against ActivePython at: http://bugs.activestate.com/query.cgi?set_product=ActivePython On what platforms does ActivePython run? ---------------------------------------- ActivePython includes installers for the following platforms: - Windows/x86 - Windows/x64 (aka "AMD64") - Mac OS X - Linux/x86 - Linux/x86_64 (aka "AMD64") - Solaris/SPARC - Solaris/x86 - HP-UX/PA-RISC - AIX/PowerPC - AIX/PowerPC 64-bit Extra Bits ---------- ActivePython releases also include the following: - ActivePython26.chm: An MS compiled help collection of the full ActivePython documentation set. Linux users of applications such as xCHM might find this useful. This package is installed by default on Windows. Extra bits are available from: http://downloads.activestate.com/ActivePython/etc/ Thanks, and enjoy! The Python Team -- Sridhar Ratnakumar sridharr at activestate.com

3 4

Re: [Distutils] how to easily consume just the parts of eggs that are good for you
by Stanley A. Klein 09 Oct '09

09 Oct '09

On Wed, April 9, 2008 10:05 pm, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > Message: 4 > Date: Thu, 10 Apr 2008 12:59:39 +1200 > From: Greg Ewing <greg.ewing(a)canterbury.ac.nz> > Subject: Re: [Distutils] how to easily consume just the parts of eggs > that are good for you > To: distutils-sig(a)python.org > > Paul Moore wrote: > >> I believe that Mac OS X goes for an even simpler structure - >> applications store *everything* in the one directory, so that >> install/uninstall is simply a directory copy/remove. > > Yep, and thereby cuts the whole gordian knot, throws the > pieces on the fire and burns them. :-) > > Package managers have always seemed to me to be an > excessively complex solution to a problem that needn't > have existed in the first place. > > I keep hoping that someday Linux will support something > like MacOSX application bundles and frameworks, but I > haven't seen any sign of it yet. > I think this discussion arises because the operating systems we are dealing with are based on very different concepts. Windows and Mac are fundamentally single user systems that have added capabilities for multiple users and are intended to be used with proprietary software. Those considerations lead to minimal dependencies among packages (each proprietary provider needs to control its own package, except for the OS), individual users serving as their own sysadmins, and similar factors. Any dependencies in the proprietary software are hidden from the user because the provider has compiled the dependencies into the binary code they supply. Unix/Linux are fundamentally multi-user systems with a distinct role for a sysadmin. Linux and the BSD's are intended to be used with Free/Open Source Software (FOSS), and Unix originated the Software Tools concept in which individual, relatively simple, separately-developed tools are combined to perform complex tasks. Both FOSS and the Software Tools concept encourage dependencies. The need for package managers arises out of the Unix FHS. If you look at the FHS, it is clearly designed to simplify the job of the sysadmin in a multi-user system that uses FOSS and Software Tools. For example, deciding what to backup and how often to do it in a Unix/Linux system is relatively easy for the sysadmin. All the installed software is in certain top-level directories. All the config files are in /etc. All the logs. caches, spools, web pages, process locks, and certain other data are in /var. All the user data is in /home or its sysadmin-determined equivalents. If the sysadmin needs space, deleting files in /tmp will not cause a problem. In summary, Python is being used on systems that have very different underlying OS use cases. To some extent, the natural use case for Python is closest to that of Linux/Unix. Running Python on Windows/Mac requires adapting for those platforms some of the kinds of tools that simplify operations on Linux/Unix systems. This discussion is essentially about how far that goes, how to accomplish it, and how to remain compatible with the existing tools on Linux/Unix. Stan Klein

4 4

tracking requested vs dependency installs in PEP 376 metadata
by Carl Meyer 08 Oct '09

08 Oct '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, I propose adding a bit to the PEP 376 metadata that indicates whether a package was installed by user request or as a dependency of another package. This would allow (un)installer tools to intelligently remove orphaned dependencies, if they so choose. There might be questions about the details of such an uninstaller feature, but I'm not intending to discuss that here. The metadata itself is simple enough to track, and seems like it ought to be included for its future usefulness. I propose adding a metadata file REQUIRED within the .egg-info directory. The presence of this file indicates that the user specifically required this distribution. The absence of the file indicates that the distribution was installed as a dependency. The contents of the file are not used. For the API, I propose adding a "required" property to the Distribution class, which would be True or False based on the presence or absence of the REQUIRED file. I've added a demo implementation to a fork of Tarek's pep376 repo on bitbucket: http://bitbucket.org/carljm/pep376/changeset/0c8002e65cb7/ Thoughts? Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKzhZa1j/fhc23WEARApy3AJ0bbzHBaS85dURlRDEcQOHlrgovXgCg022F OkpQ56+Re1yRnoNFfFNYm88= =nkMB -----END PGP SIGNATURE-----

1 0