On Wed, Sep 24, 2008 at 1:49 PM, Matthias Klose <doko@cs.tu-berlin.de>wrote:

announcing a fork without any objective? what is this fork about? if it stays 100% compatible, isn't it just more frequent releases?

This fork is about having a tool that is build for and by the community, and that does not rely on one single person, that does not have enough spare time to work on it and therefore become a bottleneck. Right now setuptools has one single person with commit privileges, and that maintains it. He is a very busy man and we have been struggling for months to speed up bug fixes and releases. This tool became a very important part of python development in many places, and we need to make it evolve faster. If setuptools development process changes, I will of course, stop the fork. Regards Tarek

On Wed, Sep 24, 2008 at 2:32 PM, Sebastien Douche <sdouche@gmail.com> wrote:

On Wed, Sep 24, 2008 at 13:49, Matthias Klose <doko@cs.tu-berlin.de> wrote:

...

announcing a fork without any objective? what is this fork about?

Python community *must* have a robust, stable and well featured infrastructure like Cpan, Gem or Apt. The actual situation is insane:

- Setuptools is not on Python core

I agree this is a shame. The boundary between setuptools and distutils is fuzzy. But if we build together a good tool, I guess it will be included at some point as a distutils replacement.

- single point failure infrastructure (pypi.p.o)

notice that there's a patch at this point that let setuptools use several indexes, it will be discussed for inclusion in Distribute 0.3

- not compatible with Hg / Bzr / Git out of the box

Notice that you can write a Manifest.in file to avoid it at this point

- missing some features

As far I see, the goal is to speed up the development of a great tool, not just a fork for fun :).

exactly !

PS: within 1 month, Ubuntu 8.10 & Debian 4.2 are out (default svn : 1.5). It's not acceptable to say "use trunk version, stupid!"

-- Seb _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

On Wed, Sep 24, 2008 at 3:08 PM, Barry Warsaw <barry@python.org> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sep 24, 2008, at 8:39 AM, Tarek Ziadé wrote:

- not compatible with Hg / Bzr / Git out of the box

...

Notice that you can write a Manifest.in file to avoid it at this point

Tarek, nice to see this hosted on Launchpad. Maintaining the code under a dvcs will be a huge win. I'm happy to provide any help with the use of Launchpad that I can. Let me also mention that Launchpad is a webservice scriptable in Python:

https://launchpad.net/launchpadlib

Great, thanks for the tips on Launchpad usage, and the support

There are several plugins for integrating setuptools with the dvcs's above. I maintain the bzr one:

https://launchpad.net/setuptoolsbzr

and would be happy to help integrate it into the core.

After the 0.1 release of Distribute (which will be Friday) , we can integrate it for the next release, the idea of 0.2 is to integrated all pending bugfixes and obvious patches Cheers

- -Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSNo75XEjvBPtnXfVAQIzTwP+K9BpTRD9nalK7JfkE0CRO/ouX1uQMhTN xiZSP9C5M4UT7jsnOeo9ylZJwmgPhP/YEgnquTNlsdEWnYTGrcXVZV22utH0t+L7 uumlmpoMN1d8UVy4DBLNz75bpW5Etx3dohwLN6Nc5lddyMa4zHCHmMJNUezmtBHF iHJPkb6Uul0= =95Dn -----END PGP SIGNATURE-----

-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

2008/9/24 Fadhley Salim <fadhley.salim@uk.calyon.com>

Is it possible to prevent setuptools from writing anything to stdout?

For various inconvenient reasons our package must install silently - that means the installation process must not write to either stdout or stderr. Other than hacking distutils / setuptools to ensure that there's nothing which can write i've not yet been able to come up with a reliable means to control output.

Thanks

At distutils level you can set the verbosity and reduce the output, by setting it to 0 (distutils.log.set_verbosity) If your package does not provocate warnings, and if the commands used are all using this log facility (iirc setuptools does it everywhereà, you should not have any output. That said, this log module should be dropped in favor of the logging module in distutils Cheers Tarek

This email does not create a legal relationship between any member of the Crédit Agricole group and the recipient or constitute investment advice. The content of this email should not be copied or disclosed (in whole or part) to any other person. It may contain information which is confidential, privileged or otherwise protected from disclosure. If you are not the intended recipient, you should notify us and delete it from your system. Emails may be monitored, are not secure and may be amended, destroyed or contain viruses and in communicating with us such conditions are accepted. Any content which does not relate to business matters is not endorsed by us.

Calyon is authorised by the Commission Bancaire in France and regulated by the Financial Services Authority for the conduct of business in the United Kingdom. Calyon is incorporated in France with limited liability and registered in England & Wales. Registration number: FC008194. Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

-- Tarek Ziadé - Directeur Technique INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632 Bureaux de la Colline - 1 rue Royale - Bâtiment D - 9ème étage 92210 Saint Cloud - France Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04 http://www.ingeniweb.com - une société du groupe Alter Way

2008/9/24 Fadhley Salim <fadhley.salim@uk.calyon.com>

I assume that what you meant to says was that we should drop the logging module in distutils and replace it with the standard python-library logger in the logging module - if so, that would be great for us.

exactly. The logging module exists for that kind of needs.

I've always wondered why distutils has it's own implementation of logging.

It's because it did not evolve at this point I guess, I will propose a patch in the python bug tracker for that. Tarek

On Wed, Sep 24, 2008 at 09:38:04AM -0400, Barry Warsaw wrote:

On Sep 24, 2008, at 9:20 AM, Tarek Ziadé wrote:

...

After the 0.1 release of Distribute (which will be Friday) , we can integrate it for the next release, the idea of 0.2 is to integrated all pending bugfixes and obvious patches

Sounds good.

Yes, thanks Tarek for doing this. We know that Philip is very busy and does not have time to review and merge in that many patches for setuptools. Hopefully this new development will help by being a fast-moving project to explore new lines and offload some work from the main project. Gaël

Sebastien Douche writes:

On Wed, Sep 24, 2008 at 13:49, Matthias Klose <doko@cs.tu-berlin.de> wrote:

...

announcing a fork without any objective? what is this fork about?

Python community *must* have a robust, stable and well featured infrastructure like Cpan, Gem or Apt. The actual situation is insane:

- Setuptools is not on Python core - single point failure infrastructure (pypi.p.o) - not compatible with Hg / Bzr / Git out of the box - missing some features

As far I see, the goal is to speed up the development of a great tool, not just a fork for fun :).

PS: within 1 month, Ubuntu 8.10 & Debian 4.2 are out (default svn : 1.5). It's not acceptable to say "use trunk version, stupid!"

For distributors like Debian, Fedora or Ubuntu, setuptools is still in a state where it's better ignored than used. It's fine to ship it, but using it in the distribution is a pain. Until today setuptools doesn't have the features needed by os distributors, and things like --single-version-externally-managed were only reluctantly added. Some things to change: - os distributors usually try to minimize the versions they include, trying to just ship one version. This single version is installed with --single-version-externally-managed, so that it can be imported without any pkg_resouces magic and fiddling with pth files. Unfortunately then it is not possible to use/import another version using pkg_resources. As discussed at PyCon such a setup is very common for os distributors. How will the fork handle such setups, and maybe incompatible changes? - setuptools has the narrow minded view of a python package being contained in a single directory, which doesn't fit well when you do have common locations for include or doc files. Does the fork accept patches to change such limitations and allowing FHS compliant packages? A branch with patches for the stable setuptools branch sounds fine. It makes it more easy to apply these fixes to the setuptools package as distributed by Debian and Ubuntu. But I doubt it will be good enough with the "compatibility approach" because changes like the ones mentioned above still seem to be left to the setuptools maintainer. Plus the name of the fork suggests that the all-coupled/all-integrated approach will live on, and distribute will remain a monolithic chunk of code. Matthias

At 04:16 PM 9/24/2008 +0200, Matthias Klose wrote:

- os distributors usually try to minimize the versions they include, trying to just ship one version. This single version is installed with --single-version-externally-managed, so that it can be imported without any pkg_resouces magic and fiddling with pth files. Unfortunately then it is not possible to use/import another version using pkg_resources.

Can we resolve this by simply documenting the __requires__ "feature"?

On Thu, Sep 25, 2008 at 5:37 PM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:

Matthias Klose wrote:

...

- setuptools has the narrow minded view of a python package being contained in a single directory, which doesn't fit well when you do have common locations for include or doc files. Does the fork accept patches to change such limitations and allowing FHS compliant packages?

Being self-contained is also a feature. People who package softwares outside distributions like this, as you are surely aware. Personally, I don't like that setuptools broke distutils install either (I prefer to manage my packages with stow, because setuptools broke too many times my setup for unknown reasons).

There should be the possibility to do both kind of installs (self-contained, or FHS compliant), but this is not so much a setuptools issue as a distutils issue, isn't it ? Dealing with this in distutils will be no fun, though...

Well, as long as things are clearly defined in the package, I guess FHS compliant package could be built with the same source tree. We could even install a distribution the FHS way or the self-contained way, as long as the tool knows what to put where. But that is already the case, a bit: For instance we have bdist_rpm, that builds rpms by mapping distutils metadata to rpm ones, The question is: starting with the current MetaData what would you miss to do a FHS installation ? Take a look at http://www.python.org/dev/peps/pep-0345/

cheers,

David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

On Thu, Sep 25, 2008 at 6:39 PM, David Cournapeau < david@ar.media.kyoto-u.ac.jp> wrote:

Again, other people know distutils much better than me and may disagree with me, or maybe rightfully notice my lack of experience on that codebase, but from my own work on it - which while not complicated was not trivial either - I got the conviction that any fundamental change wrt distutils will be extremely painful to do if not impossible in a backward compatible way. I was hoping that a distutils replacement would come for Py3k, actually :)

Well, everyone seem to agree on that: let's create a full, new replacement.