http://blog.gmane.org/gmane.comp.python.catalog hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.python.catalog/1686 Hello there, There's an item named "dateutil" in PyPI which I'm unable to edit/remove. The actual project name I usually maintain is "python-dateutil", and it has the latest versions of the software. Can you please give me hand to kill the "dateutil" one? Thanks! Gustavo Niemeyer 2008-11-20T20:29:42 http://comments.gmane.org/gmane.comp.python.catalog/1684 I'll be upgrading the machine that has PyPI on it tomorrow (Saturday) around 8:00 UTC. PyPI (and the Wiki) will be down. Regards, Martin Martin v. Löwis 2008-11-14T10:03:36 http://comments.gmane.org/gmane.comp.python.catalog/1682 Hello I would like to know if people would be interested in some events during Pycon: - a Sprint for packaging+PyPI matters (already submited) - a "packaging" panel during Pycon "release/distribute a Python application today, solutions and problems" For the latter, let me know here or in private if you would like to contribute to that panel a good panel would probably require os packagers and people from these two MLs to be involved. If I have enough people interested I will submit this panel as a proposal for Pycon. Cheers Tarek Tarek Ziadé 2008-11-07T17:25:35 http://comments.gmane.org/gmane.comp.python.catalog/1679 Hi ! Sorry for the crosspost, but this mail concerns both lists, There are two points that need to be discussed to finish the work on the PyPI proposal started in D.C. (http://wiki.python.org/PEP_374): - the fail-over mechanism - merging several indexes *Fail over* PyPI will provide a static page that lists all its mirrors. Each line of this file describes a mirror. It provides the root url, followed by the relative url of: - the index : the root of the package index - the last-modified page : a static text file that gives the date of the last sync. - the local stats page: a static text file that gives the number of downloads of a file, per package, per user-agent - the global stats page, calculated by pypi that gives the grand total of all downloads (the sum of PyPI local stats + mirrors local stats) - the mirrors page, that lists all mirrors For example: http://example.com/pypi,index,last-modified,local-stats,stats,mirrors http://example2.com/pypi,index,last-modified,local-stats,stats,mirrors (see the proposal doc for more info) This mirror list says for example that a mirror is available at http://example.com/pypi/index, and that its last modified date is available at http://example.com/pypi/last-modified. On client side it means that it is possible to list mirrors of a given package index to implement a fail-over mechanism. Moreover, it makes it possible to select the nearest mirror. *Merging several indexes* Besides fail over, another thing needs to be implemented on client side: being able to use different indexes. This is an obvious missing feature: we don't want to push in PyPI all our customers package. In the meantime we do want to use tools like distutils, setuptools etc., the same way with any kind of package. So using private package indexes easily besides PyPI is needed. It is now possible in Python 2.6 with the new .pypirc file to define several indexes. work with other indexes than PyPI. But tools like setuptools need to evolve the same way. Each one of this index can have its own mirrors, as defined previously, but the client needs to combine all the different index, into a "super" index. This can be implemented by working with a sorted list of index. When a client is looking for a package, it can look in each index and pick the first package that fits. Any comments ? Cheers Tarek Tarek Ziadé 2008-10-26T22:01:06 http://comments.gmane.org/gmane.comp.python.catalog/1675 The subject line pretty much says it all. I'd like to know when those files were uploaded. Regards, Zooko --- http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $10/month zooko 2008-10-25T01:39:35 http://comments.gmane.org/gmane.comp.python.catalog/1665 *** Your message was blocked due to the attachment type. *** Message [oc4cbf517104849c0bfa2c8ca329464e9.pro] triggered rule [File Attachments] at 4:57:10 AM 10/19/2008 Sender: catalog-sig< at >python.org Recipient(s): asamuels< at >dot.state.az.us Subject: RETURNED MAIL: DATA FORMAT ERROR_______________________________________________ Catalog-SIG mailing list Catalog-SIG< at >python.org http://mail.python.org/mailman/listinfo/catalog-sig administrator< at >azdot.gov 2008-10-19T11:57:10 http://comments.gmane.org/gmane.comp.python.catalog/1663 As suggested in issue 2169549, I have now added a number of trove classifiers to PyPI to denote support for certain Python versions, namely Programming Language :: Python :: 2 Programming Language :: Python :: 2.3 Programming Language :: Python :: 2.4 Programming Language :: Python :: 2.5 Programming Language :: Python :: 2.6 Programming Language :: Python :: 2.7 Programming Language :: Python :: 3 Programming Language :: Python :: 3.0 Programming Language :: Python :: 3.1 With these, packages can indicate that they support 2.x (but not 3.x), or that they have been tested/written for specific Python releases. As a side effect, packages can now expressly state that they support Python 3000. Regards, Martin Martin v. Löwis 2008-10-18T13:00:48 http://comments.gmane.org/gmane.comp.python.catalog/1657 _______________________________________________ Catalog-SIG mailing list Catalog-SIG< at >python.org http://mail.python.org/mailman/listinfo/catalog-sig Drew Hess 2008-10-16T04:46:58 http://comments.gmane.org/gmane.comp.python.catalog/1640 _______________________________________________ Catalog-SIG mailing list Catalog-SIG< at >python.org http://mail.python.org/mailman/listinfo/catalog-sig Mark Hall 2008-10-13T12:42:27 http://comments.gmane.org/gmane.comp.python.catalog/1607 Here's the lists of tasks we are going to work on. They are simple. - PyPI : write a patch to enforce (or display a warning) the source distribution to be uploaded. so if a binary distribution or a zipped egg is uploaded we are sure we provide the source as well. - Documentation: write a glossary for the distutils/setuptools/Pypi terminology on python.org wiki - PyPI mirroring: write a PEP to implement a mirroring protocol, where mirrors can register at PyPI. Then when a package is uploaded, mirrors will be ping through RPC so they know they can eventually get synced. - setuptools: finish the patch for the multiple index support, with a CPAN-like mechanism on the client side, with a socket timeout managment - - distutils: code cleaning: better test coverage, remove logging, etc. Tarek Tarek Ziadé 2008-10-11T17:56:27 http://comments.gmane.org/gmane.comp.python.catalog/1591 Hi there, I would like to inform you that we created the "PyPI replication project" hosted on Launchpad. Driven by the needs of the Zope world using zc.buildout intensively, we created a package z3c.pypimirror for mirroring the packages directly hosted on PyPI on a local server. This removed the dependency from the PyPI server(s) which are a single-point-of-failure and often had issues in the past with respect to availability and reliability. In phase 1 of the project (upcoming soon) we will provide a number of independent machines (up to five servers) with a full copy of all packages hosted directly on PyPI. For phase 2 (next year) we will rework the codebase of z3c.pypimirror and try to deal in some way with packages hosted externally. In addition we think about providing some kind of automatic mirror-selection within setuptools/zc.buildout based on DNS alias entries (subject to be planned). Andreas _______________________________________________ Catalog-SIG mailing list Catalog-SIG< at >python.org http://mail.python.org/mailman/listinfo/catalog-sig Andreas Jung 2008-10-09T10:40:14 http://comments.gmane.org/gmane.comp.python.catalog/1580 Hey all, We are going to have a P4-sprint (pre-pre-pre-PEP sprint) in D.C. during the Plone Conference. The idea is to try to bring the discussions that have been going on in the mailing lists into the next stage. Please join us if you are interested, even if you are not in D.C. http://www.openplans.org/projects/plone-conference-2008-dc/distribute Regards Tarek Tarek Ziadé 2008-10-07T14:35:49 http://comments.gmane.org/gmane.comp.python.catalog/1575 hi~ I'm writing pypi2pkgsys: http://code.google.com/p/pypi2pkgsys/ . I noticed that the name, license of python modules registered in PyPI is really a miss. Such as 'Are You Human?', even easy-install can not install them with these strange name. Most of the linux user use a linux distribution, such as fedora, ubuntu or gentoo, I'm not willing to install python module by easy-install because the local package management system will not know the python module is installed already. They will install them with some old version again. If PyPI is more strict in name, license and its format, automatically package install within the distribution package management system should be possible. By the way, PyPI is really slow here, mirror should be welcomed. And I have add the local mirror features into pypi2pkgsys. Thanks. Any comment is welcomed. Charles Oct 6th, 2008. li wang 2008-10-06T06:09:13 http://comments.gmane.org/gmane.comp.python.catalog/1549 _______________________________________________ Catalog-SIG mailing list Catalog-SIG< at >python.org http://mail.python.org/mailman/listinfo/catalog-sig Dinu Gherman 2008-10-01T12:35:05 http://comments.gmane.org/gmane.comp.python.catalog/1548 Hello I have followed most of the threads from the past days, and we talked a lot on IRC with people from Fedora, Debian, Enthought, TG2 on possible enhancements While the other threads are continuing in deeper details, I would like to start a fresh thread were people don't have to re-read everything to be able to give their opinions on very precise points, This thread is focusing on shouting out the current problems and the solutions that can be adopted. I'd like to have "+1" and "-1" on each proposal, with at most one sentence. or fix a mistake if there is. That could help us speed up the work. let's try to keep this thread concise, if you want to discuss deeply on a problem, start another thread, and i'll follow it to fix my summary. The problems =========== 1/ the dependencies of a package are not expressed in the Require metadata of the package most of the time. adding a dependency to a module is not really done, developer add dependencies to packages. Furthermore, developer tend to use setuptools "install_requires" and "tests_require" arguments to express dependencies. So basically, you have to run an egg_info to get them, because the info files are generated by commands. 2/ the existence of PyPI had a side-effect: people tend to push the entire doc of the package in one single field (long_description) to display them at PyPI. The documentation of the package is not cleary pointed to others. 3/ the metadata infos cannot be expressed in a static file by the developer, because sometimes they are calculated by code. while this very permissive, that is how it works but they are tighted to argument passing to setup(). 4/ PyPI lacks of direct information about dependencies. In the meantime, the DOAP project is working on a way to express dependencies, but it is a work in progress. 5/ ideally, they should be one and only one version of a given package in an OS-based installation 6/ packagers would like to have more compatibility information to work out on security upgrades or version conflicts 7/ developers should be able to have more options when they define version dependencies in their packages, things like: A depends on B>=1.2 and B<=2.0 but with a preference to B 1.4 or "avoid B 1.7" they give tips to packagers ! 8/ the requires-python field is rarely used by people, so unless you try the package, you don't know when it is a source distribution, if it is going to run on various python versions. 9/ unless the developer has a strong comitment to an OS, he will never create and use a file that is located in /etc 10/ you can't possibily have a complete knowledge of the dependency graph and possible conflicts when you introduce a versioned dependency in your package. packages at given versions are known by some people to work well together or not in a set of versioned packages, Let's call this a "known good set" (KGS) - OS packager know and maintain the KGS for their distribution. - Web framework packagers does it for their application you don't. unless you work in a "KGS" environment. But if you want your package to be a regular python package at PyPI, packagers should be able to change its dependencies to make it fit their own KGS, and to build their knowledge on it. The developer dependencies infos is a tip and a help for a packager, not an enforcement. see [7] 11/ people should always upload the sdist version at PyPI, they don't do it always. otherwise it is a pain for packagers. Proposals ======== this is also a synthezis of what I hurd, and some elements I have added to respect the needs that were expressed. 0/ a lot of work can be done to clean distutils, no matter what is decided (another PEP is built for that) cleanning, removing old-style code, testing 1/ let's change the Python Metadata , in order to introduce a better dependency system, by - officialy introduce "install requires" and "test requires" metadata in there - mark "requires" as deprecated 2/ Let's move part of setuptools code in distutils, to respect those changes. 3/ let's create a simple convention : the metadata should be expressed in a python module called 'pkginfo.py' where each metadata is a variable. that can be used by setup.py and therefore by any tool that work with it, even if it does not run a setup.py command. This is simpler, this is cleaner. you don't have to run some setup magic to read them. at least some magic introduces by commands 4/ let's change PyPI to make it work with the new metadata and to enforce a few things Enforcements: - a binary distribution cannot be uploaded if a source distrbution has not been previously provided for the version - the requires-python need to be present. : come on, you know what python versions your package work with ! New features: - we should be able to download the metadata of a package without downloading the package - PyPI should display the install and test dependencies in the UI - The XML-RPC should provide this new metadata as well. - a commenting system should allow developers and packagers to give more infos on a package at PyPI to make the work easier Open question ============ (please if you want to react on those, open another thread, with a clean cut, otherwise it is hard to follow directly) - what about the documentation ? can't we express it better in the Metadata ? I think we can structurize it a bit - what about the configuration ? can't we find a way to interact with a config ini-like file for instance and don't care if it is located at /etc/package.cfg or at /Volumes/..etc ? Regards Tarek Tarek Ziadé 2008-10-01T12:10:48 http://comments.gmane.org/gmane.comp.python.catalog/1529 _______________________________________________ Catalog-SIG mailing list Catalog-SIG< at >python.org http://mail.python.org/mailman/listinfo/catalog-sig Florian Friesdorf 2008-09-15T12:38:07 http://comments.gmane.org/gmane.comp.python.catalog/1528 Hi. I need to change my email address on PyPI but I'm having problems. I log in, click on "Your Details" on the top right, and try to change my email address. If I try to just change my email address, I get this error message: ----- Error processing form password is required ----- If I then enter my password (in addition to my email change), I get this error message: ----- User registration user "gary" already exists ------ Could someone help? Thank you Gary Gary Poster 2008-09-14T17:17:56 http://comments.gmane.org/gmane.comp.python.catalog/1526 I noticed that you can upload documentation for packages in PyPI, so I took advantage of that for the lockfile module: http://pypi.python.org/pypi/lockfile http://packages.python.org/lockfile/ I don't see any links to the latter URL at the former though. How are users supposed to know documentation is available online? I don't see a link on the lockfile page. Thx, Skip skip< at >pobox.com 2008-09-14T03:42:14 http://comments.gmane.org/gmane.comp.python.catalog/1523 Hello Everybody, I am new to this list and found the discussion about PyPI Mirrors in the archieves. I am working at the German Aerospace Center where I have just started development of a PyPI mirroring solution which addresses a few issues in QA and Continous Integration we encountered here. For Java/maven based projects we use Sonatype-Nexus (http://nexus.sonatype.org/) Which solves a lot of problems there but does not help with python. It should be able to proxy/mirror any number of package indexes (storing all the files that have been downloaded once.) It should be able to host multiple indexes which are available under different urls and which may or may not restrict access to certain users. It should be possible to combine several mirrors and/or hosted repositories into groups which appear to be a single repository. It should integrate with LDAP/Activedirectory (at some time) Anyway... the project is in early planning and will be available under Apache License 2.0 The project has been registered at Sourceforge just yesterday (https://sourceforge.net/projects/hatchery/) There is nothing there yet, but hopefully that will change soon. If you have specific features you would wish for in a mirroring/hosting solution Please tell me. Discussion and participation is always welcome. Kind regards, Roland Gude Gude.Roland< at >dlr.de 2008-09-03T09:26:17 http://comments.gmane.org/gmane.comp.python.catalog/1522 Hello, I'd like to request a category for plugins of the repoze.who framework, which can be "Framework :: repoze.who :: Plugins". I already have a plugin for this framework: http://pypi.python.org/pypi/repoze.who.plugins.ldap/ Thanks in advance. Gustavo Narea 2008-08-30T21:04:44 http://comments.gmane.org/gmane.comp.python.catalog/1521 _______________________________________________ Catalog-SIG mailing list Catalog-SIG< at >python.org http://mail.python.org/mailman/listinfo/catalog-sig vin vin 2008-08-29T08:50:40 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.catalog