Great mail ! This has to be published somewhere like Jacob is suggesting.
I'd like to react on the PyPI part: On 15 sep, 04:52, Kevin Teague <[EMAIL PROTECTED]> wrote: > > PyPI > ----- > > Everyone knows what this is (hopefully!). A small point to note is > that it was originally called The Cheeseshop, there was a long thread > started by people who didn't like the name, and it was renamed to PyPI > and use of the name Cheeseshop is politely discouraged. > > While there is only one PyPI, tools that pull packages from here > (easy_install and buildout) can easily pull from additional package > repositories. These can be mirrors, local caches, private repos, or > whatever. Creating your own repo is as easy as dropping a Python > packaged .tar.gz file into a directory and exposing it using Apache's > default directory views feature. There are also cool projects recently > started such as z3c.pypimirror which lets you create a local PyPI > mirror, but rather than mirror all 4+ GB of PyPI, it will only mirror > packages *as you request them*, very cool and probably something that > would be quite neat in a shared hosting environment. As far as I know (and as I said to Andreas Jung when they created this package during a sprint lately), z3c.pypimirror is a *full* mirror. It doesn't allow you to get only some packages. It has a name filter, so you can get for instance all package that starts with "foo." but this is a non sense because this package might have a "bar" package in its dependency, it won't grab it. So basically it is a rsync, and rsyncing 5 gigas is taking a bit of time (I think they are taking care of this aspect now, I am not sure though) We developed before z3c.pypimirror a package called iw.eggproxy that is a proxy that will simply get all the package tools like easy_install or buildout are asking for. So if you work in a zope environment it will get only the package you work on. > > Django really needs to update their PyPI page - it hasn't been updated > since 0.91! And it's not classified under the Frameworks::Django trove > either: > > http://pypi.python.org/pypi/Django/ > > As far as "flooding" PyPI with packages, Zope2+Zope3+Plone has 1,236 > packages on PyPI right now. There have been one or two grumbles about > this (it would seem people will grumble about just about anything), > but I'm pretty sure the consensus is if the number of packages becomes > unwieldly, the solution is to improve PyPI itself and not "start more > PyPIs". > > The only valid grumbles about heavy PyPI usage are: packages with > really sparse classification and documentation, releasing -dev > packages onto PyPI (don't do this!), and especially *don't remove a > older packages* (really please, please don't do this!). > > Plone add-ons were released to the Plone Software Center before PyPI > existed. Tarek Ziade has done awesome work at making it possible to > seamlessly release Plone add-ons to both plone.org and PyPI. This way > a package can have additional Plone-specific metadata, but still have > a PyPI presence without creating a bunch of extra maintenance work for > the add-on developer. I tried to use PyPi software at first but it was hard to reuse. I have created this PloneSoftwareCenter extension in order to be able - to make plone.org accept eggs through distutils calls, like you said (otherwise the products section of plone.org is doomed, facing pypi's one) - to run my own PyPI for private packages But there's a very important point about this work: I don't want PyPI to be a single point of failure. PyPI server is pretty robust, but I don't want my developers to depend on it while they are working. It happened in the past that we couldn't work because of that, because zc.buildout grabs a myriad of eggs at pypi to build Plone, and because we are building and upgrading buildouts all day long. (We have mirrors and caches everywhere now ;) ) Our strategy for the future on this will be to be able to use distutils/setuptools and zc.buildout with several packages indexes (pypi, plone.org or any other), and to push packages on several places and sometimes with extra metadata like you said (plone.org will have a rating system) I have changed Python 2.6 for that (http://tarekziade.wordpress.com/ 2008/05/12/the-new-pypirc-format-in-python-distutils/) so you can deal with several pypi-like servers and I have a patch in setuptools that is pending, so easy_install can play with several servers as well/ So basically, a developer will be able to push any package to any server, and a tool like zc.buildout or easy_install will be able to get a package from a list of pypi-enabled servers. (and if one of them is down , the package might be in to another one) So if you decide to deploy Django like zope, at pypi, I would encourage you to set up your own community pypi-like server, like we are going to do on plone.org. The work done on python, setuptools, zc.buildout and Plone.org to make this possible in Plone will be presented in a tutorial at the plone conf in DC in two weeks. I think it can be interesting for the django community to take a look at it. Cheers Tarek --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
