Mailman 3 October 2009 - Distutils-SIG

Distribute and setuptools: what are the differences
by Michael Whapples 13 Oct '09

13 Oct '09

Hello, I realise I may be starting something I would prefer not to (looking at some of the replies of the announcement of setuptools 0.6c10), so I would like to ask that this tries to stay as a factual thing rather than a "having a go at the other". As it seems that setuptools is not "dead" just possibly a bit slow at being updated, could I ask what are the aims of the various projects setuptools and distribute (please try and keep this information restricted to your project and what it aims to do)? It would be nice to have this information as at the moment its a bit unclear what either really are trying to offer over the other. I would like to be able to make a fully informed choice on why use one over the other, I feel at the moment this isn't possible. I have to say from my view (as a developer of my own packages only using setuptools/distribute to help package my packages) that it currently looks a horrible mess, distribute tries to replace setuptools and does it in such a way that any package which specifically wants setuptools has to use distribute if another package wants it, so not allowing the one which specifically wants setuptools to get the latest setuptools (eg. now or soon it will be setuptools 0.6c10). It is tempting for me to use distutils and create my own custom code to give the features I currently really use from setuptools/distribute until this "mess" has been cleaned up. I know this idea of going a custom route doesn't really help things, but my main concern is my package and if no solution currently can satisfy me it is suitable then unfortunately custom solutions may be the best option for me (I won't support a mess). Michael Whapples

6 9

Problem with distribute and converting tests for python3
by Michael Whapples 12 Oct '09

12 Oct '09

Hello, Firstly thanks to those working on distribute, I had been using setuptools but was getting annoyed with it slowly developing (eg. not having python3 support, etc), so distribute seems like it is what I am looking for. Any way I am using distribute for one of my packages now (I wanted to try and support python3) but have noticed something which doesn't work for me. I have my main package sources in one directory and then tests in another directory (it makes it easy to separate them out when creating a binary package). Now this works fine for python2.x as I can include the tests in a source distribution by using MANIFEST.in, but it doesn't work for python3 as distribute doesn't seem to run 2to3 on them (although they are run by the distribute/setuptools test command in the setup.py script). When I looked at the distribute documentation the example there has the tests in a subpackage of the main package. So my question is, am I structuring my source distribution wrongly, is there a better way to do this which would work with distribute? If I were to structure my source distribution like the distribute example then how do I ensure unit tests aren't included in a binary distribution? Is there anyway I can get distribute to pick up my tests as I currently have my source distribution structured? Michael Whapples

3 8

Re: [Distutils] PEP 390 - new format from setup.cfg
by Stanley A. Klein 12 Oct '09

12 Oct '09

On Mon, October 12, 2009 12:24 am, Tarek Ziad? <ziade.tarek(a)gmail.com> wrote: ------------------------------ > > Message: 2 > Date: Mon, 12 Oct 2009 00:17:10 +0200 > From: Tarek Ziad? <ziade.tarek(a)gmail.com> > To: distutils-sig(a)python.org > Subject: [Distutils] PEP 390 - new format from setup.cfg > Hey > > this is the PEP for setup.cfg, as requested : > http://www.python.org/dev/peps/pep-0390 > > Please comment, > > Tarek > It isn't clear in the new format how one would set up a bdist_rpm for an SE-Linux system (such as Fedora or Centos) that has required pyc and pyo files to be included in the package. In the past this has been done using entries in setup.cfg. Stan Klein

1 0

distribution packaging from Distribute
by Rakotomandimby Mihamina 12 Oct '09

12 Oct '09

Hi all, Would you know a tutorial on Debian packaging from buildout/distribute? I mean: - I setup the buildout.cfg - I run buildout with Z or X option - I get the package I dont mind if it's not entirely Debian compatible (python and some libs duplication). Any link? Thank you. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 34 29 155 34

3 7

distribute or Distribute
by Reinout van Rees 12 Oct '09

12 Oct '09

I'm probably overlooking it somewhere in the documentation: should I specify a distribute dependency as "distribute" or "Distribute"? I'm used to lowercase so that's what I'm using till now, but I've spotted a Capital Letter somewhere... So which one is preferred? Reinout -- Reinout van Rees - reinout(a)vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"

2 1

Eggs vs bdist_wininst (Was: Distutils and Distribute roadmap (and some words on Virtualenv, Pip))
by Paul Moore 11 Oct '09

11 Oct '09

2009/10/9 Michael Foord <fuzzyman(a)voidspace.org.uk>: > Many Windows users would be quite happy if the standard mechanism for > installing non-source distributions on Windows was via the wininst binaries. Actually, my understanding is that easy_install is perfectly able to use (download, unpack and install) bdist_wininst packages. So *as a binary distribution format* bdist_wininst installers can do all that eggs can, plus extra (install themselves unassisted!) So why is there a need for an egg binary format on Windows? Paul.

3 4

Re: [Distutils] [Python-Dev] Bits-of-Distribute naming
by Fred Drake 11 Oct '09

11 Oct '09

On Fri, Oct 9, 2009 at 12:08 PM, Chris Withers <chris(a)simplistix.co.uk> wrote: > distutils.entrypoints would seem to be the sensible place. Why's that? On the whole, I don't think entry points are specific to building & bundling, which is what distutils is all about. Entry points are about packages being able to provide metadata about how parts of them can be used. I'd rather see a pkgutil.entrypoint module with APIs for this. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller

3 2

PEP 376 unclarity about function of INSTALLER
by Carl Meyer 11 Oct '09

11 Oct '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, PEP 376 contains this line, regarding the INSTALLER metadata: "This allows a third-party application to use the uninstall function and make sure it's the only program that can remove a distribution it has previously installed." This sentence seems misleading to me. "We're all consenting adults here" and whatnot; it's not really possible for an installer to "make sure it's the only program that can remove a distribution it has previously installed." At best it is providing strong guidance. Perhaps replace "make sure it's the only program that can remove" with "strongly suggest that no other program remove"? Carl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK0i9H1j/fhc23WEARAoHrAKCv0EBG5HrjiSxBxJkNga8zmKmJTQCgtp1m RrLsw0+7LA1MHBqfYN+Vk9c= =nPHV -----END PGP SIGNATURE-----

2 1

Packaging Distribute
by Akira Kitada 11 Oct '09

11 Oct '09

Hi, I'm planning to make a port for Distribute to make it more accessible to users. However, thinking about up coming 0.7 release, which will break the compatibility with setuptools, I started wondering it's not so easy to make a package for distribute. If I understand correctly, Distutils 0.7 is like Python 3.x in some ways. It breaks compatibility and 0.7 and 0.6 both will continue to be developed in parallel at least a year or so. That sounds great but we can't have two versions of a Python module at the same time. Take a Jinja and Jinja2 for example. It has to have different names to make both package available at the same systen at the same time. For Distribute, there would be a few options to work around this: 1) Make 0.6 and 0.7 different package, like Distribute and Distribute2 (Jinja like solution) 2) Make 0.7 fat package, which includes 0.6(setuptools compat) features as deprecated. *) YOUR IDEAS COME HERE. Is there anyone having any other solutions? And what actually Distribute developers are thinking about this problem? # I heard Gentoo provides Distribute as setuptools but I think it's rather rude Thanks in advance.

12 17

Distribute 0.6.4 released !
by Tarek Ziadé 10 Oct '09

10 Oct '09

Hello On behalf of the Distribute team I am happy to announce the release of Distribute 0.6.4. - This release is now compatible with zc.buildout, as long as you use the special bootstrap.py file provided at nightly.ziade.org/bootstrap.py - A new upload_docs command to easily upload project documentation to PyPI's http://packages.python.org was added. As a matter of fact, Distribute documentation is now available at : http://packages.python.org/distribute - A bug was fixed in the bootstraping process (IOError: Could not build the egg) The release is available at PyPI, together with the installation instructions: http://pypi.python.org/pypi/distribute The next release in the 0.6.x will continue the work on fixing bugs (see http://bitbucket.org/tarek/distribute/issues) Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

1 0