Re: [Python-Dev] eggs now mandatory for pypi?
On Mon, Oct 05, 2009 at 10:43:22AM +0200, Fredrik Lundh wrote:
Greetings effbot. :) As you might already know, "eggs" are not mandatory for pypi. No where in the documentation it mentions so. Also many good packages in pypi are not eggs (MaL's egenix packages for e.g) and we have known his dislike for that particular format too. But still, sometimes people have found eggs to be convenient. That was a particularly harsh comment from jensens, should be ignored or he should be corrected that eggs are not mandatory. But, i have a feeling that this is going to open up the well known, can-of-worms on what is the best distribution format for python packages debate. -- Senthil No one may kill a man. Not for any purpose. It cannot be condoned. -- Kirk, "Spock's Brain", stardate 5431.6
Senthil Kumaran wrote:
I don't dislike the format itself, just the tools that are available for using it. We've implemented our own bdist_egg now which doesn't use setuptools and will start to ship eggs in addition to our prebuilt format with the next releases. As time permits, we'll also write an egg installer/uninstaller (one that does only that ;-).
Let's hope not :-) Besides, the discussions should be about the tools used for package distribution - the egg format itself is fine. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
M.-A. Lemburg wrote:
Egg-cellent ;-) Any chance this tool is open source? Better yet, could it make its way into distutils asap? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
mxSetup.py, the module implementing all our distutils extensions, is available in egenix-mx-base which is open source: http://www.egenix.com/products/python/mxBase/ Here's current snapshot: http://downloads.egenix.com/python/egenix-mx-base-3.2.0_20091006.zip or as egg http://downloads.egenix.com/python/egenix_mx_base-3.2.0_20091006-py2.6-linux... Note how the package name is mangled... easy_install requires this. The file name also doesn't tell you that the above is for a UCS2 Python build. Again, easy_install fails with that information added to the "py2.6" version marker. We're still tweaking the implementation a bit, but it's stabilizing rather quickly. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
M.-A. Lemburg wrote:
I have memories of mxBase having a load of other stuff in it too? Would it be possible to split just the distutils extensions into their own package and get that package as an sdist on PyPI? That said, I still think getting the bdist_egg code, at least, into Distutils in the core as soon as possible would be a very good thing. It's kinda odd having the python equivalent of jars or gems only being created by third party software that's no longer maintained...
Surely this stuff all belongs in the static metadata file that keeps on overcomplicating itself in discussions? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
I'll make the argument that feedback is useful, comments are much less so and a lot more work. It would be more useful to allow package users post feedback, visible only to the package maintainer, and also add support for bugtracker links/etc. Is the intention of Pypi really to turn it into a social networking site?
Chris Withers wrote:
Yep, lots of it.
Would it be possible to split just the distutils extensions into their own package and get that package as an sdist on PyPI?
Nope. The main reason for having switched to distributions is to make things easier to manage - both for us and our users.
The complicated stuff does belong somewhere else, but the basic things need to go into the filename - simply because you have to build separate files for each Python build dimension and want to be able to put everything into a single directory or index: * Python version * Architecture/Platform * UCS2/UCS4 E.g. to solve the UCS2/4 part, we had to setup separate PyPI-style index sites. We'd really like to avoid that if possible. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
M.-A. Lemburg wrote:
shame :-(
The complicated stuff does belong somewhere else, but the basic things need to go into the filename
But everyone's basic things are different.
Well yeah, and the only sane way I can think to handle this is to have a metadata file that gets uploaded with each distribution that covers all these things (and the other things that other people need) and then have the index (which would hopefully be PyPI on the whole) be queryable along the lines of "give me a download url for a distribution named X that is for Python 2.6, Win32, UCS4, PostGreSQL 8.5, BlagBlah"... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
The really basic stuff is the same for everyone since it's dictated by the way Python works on computers :-)
So you want the indirection to happen even before fetching the download package ? That's a good idea - and also a lot better than the web page link scanning that setuptools is doing. It goes a bit in the direction of what we had in mind with writing for our clients: a tool that looks at the Python installation and automatically finds/downloads/installs the right package from our website. Only that we wanted to put up a single index file for that tool to use, not one per package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
At 06:03 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
They're not mutually exclusive, btw. More information could be added to the PyPI "Simple" API to include this sort of thing, visible to newer installers and invisible to older ones. The main reason why easy_install has a relatively simple, REST outgoing API is that it allows people to make their own compatible indexes just by throwing some files in a directory and turning on Apache directory indexing. By using a... what do they call it, "microformat"? to mark up other information in the file, it'd still be possible for someone to slap up a web page and use it as a package index.
That'd get a bit big for PyPI, though, with thousands of listed packages. It's already pretty slow whenever somebody miscapitalizes or mis-punctuates a package name and easy_install has to read the "file" that just lists all the package names. That, of course, is more a function of the fact that PyPI's "simple" API doesn't support canonicalization, although I believe certain other PyPI-mirroring and package indexing apps do.
P.J. Eby wrote:
The above was only meant for our eGenix packages, not PyPI. For PyPI the natural answer to this is to use the already existing PyPI XML-RPC interface: http://wiki.python.org/moin/PyPiXmlRpc This would only have to grow a few more fields for the release downloads in order to be able to match the user's Python configuration to the available release downloads. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
At 10:17 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
Yes, but it's not easily duplicated by somebody who's just got a plain ol' web page, nor is it amenable to static page mirroring. A GET-only REST API, on the other hand, is compatible with both.
On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers <chris@simplistix.co.uk> wrote:
Exactly. I'd like to see that and it sounds like a very simple and reasonable proposal. One could say that much of the setuptools cloud came about because of the lack of the queryable download url. Setuptools does a lot of work here to 'work-around' the ommission on pypi of a package download url. I'm just with you 100% on this... David
David Lyon wrote:
I think you two have missed my email to PJE. In summary: PyPI already does have mechanism for querying download URLs. http://wiki.python.org/moin/PyPiXmlRpc It only lacks some more meta-data that would be required to match up the user's configuration with the one used in the uploaded URLs. And it would be handy to have a mechanism to just upload the URL data rather than the whole package. Looking at distutils' upload command, PyPI currently appears to only support uploads of the package file itself. Basically, most of the mechnisms are already there, they just need some extra care. BTW: Who would I need to contact for the PyPI side to work out an upload_url distutils command ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 08 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Thu, Oct 8, 2009 at 9:35 AM, M.-A. Lemburg <mal@egenix.com> wrote:
BTW: Who would I need to contact for the PyPI side to work out an upload_url distutils command ?
I am not sure to understand. How upload_url will differ from the register command that let you upload metadata at PyPI ? Tarek
Tarek Ziadé wrote:
The register command only uploads the package's meta-data. The upload command uploads a file and registers the file's details with PyPI as well. I'd like to add an upload_url command which only registers a file's details (including the URL, but without the actual file) with PyPI and perhaps extend the number of attributes sent to PyPI with more file configuration information (upload currently only sends the Python version). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 08 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Thu, Oct 8, 2009 at 10:38 AM, M.-A. Lemburg <mal@egenix.com> wrote:
Sounds like an option to be added in upload.
-- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
Tarek Ziadé wrote:
With a little code refactoring that would be possible as well, yes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 08 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Thu, 08 Oct 2009 09:35:57 +0200, "M.-A. Lemburg" <mal@egenix.com> wrote:
Maybe you're right. I'll look into it.
BTW: Who would I need to contact for the PyPI side to work out an upload_url distutils command ?
pypi is on sourceforge... ask to become a developer I guess.. David
David Lyon wrote:
I know that the issue tracker for PyPI is (still) on SF, but development appear to happen elsewhere and I can't find any contact information on the PyPI web pages. Is Richard Jones still working on it ? They I could contact him directly to hash this out. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg <mal@egenix.com> wrote:
Everything is provided here: http://wiki.python.org/moin/CheeseShopDev
Is Richard Jones still working on it ? They I could contact him directly to hash this out.
I think Martin vL is the most active developer at this time. Regards Tarek
Tarek Ziadé wrote:
Thanks for the URL.
Ok, then I'll coordinate with Martin. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
"Martin v. Löwis" wrote:
Ok, then I'll sign up there. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 10 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
At 03:18 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
Btw, every couple years or so I've sent out a call on the distutils-SIG to try to get consensus on a format for the platform tag information used by setuptools. (The first time was before easy_install even existed.) Unfortunately, it's rare that anybody contributes more than criticism of the existing scheme. The last updates to the scheme were by Mac folks, who at least had a clear vision of what was needed. There's been some win32/win64 discussion in the past, but no proposals or patches of comparable specificity. Linux and other unices haven't had any concrete suggestions at all, AFAICR. Anyway... just saying that if you *have* a concretely implementable proposal about what to do with platform tags, please do share on the distutils-sig. Platform tags are one area that's reasonably easy to upgrade in a backward-compatible-ish way; newer versions of easy_install can still recognize older tags, although new eggs won't be recognized by older installers (forcing people to upgrade setuptools in that case).
P.J. Eby wrote:
Here's a very simple Python version scheme we've been using for years: pyX.X_ucsY with X.X being the major.minor Python version and Y being either 2 or 4 depending on the UCS-build that was used to build the egg. The "_ucsY" part is not needed for pure-Python archives (but it doesn't hurt using it there as well) and also not needed on Windows, since Python is always UCS2 on Windows. easy_install should first look for the full version string and then fall back to the non-UCS one. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Tue, 06 Oct 2009 13:52:34 -0400, "P.J. Eby" <pje@telecommunity.com> wrote:
Consider the fact that Mac users won't answer or discuss posts by some windows users.. Why do this ? Why stir up platform bias? Fact is Phil, windows users get *turned-away* at the door in distutils... or ignored. Issues can hang around for years. And your post is now asking "why no windows users?" Go figure.. nobody answers them or takes issues seriously. Distutils for windows is very, very dead.. grave-ware in-fact. It should be quite obvious that windows users are forked off.. Why would windows people make proposals when they know it won't go anywhere... David
David Lyon wrote:
Distutils for windows is very, very dead.. grave-ware in-fact.
Now that is not true at all. We have a native Windows installer (bdist_wininst) and an MSI builder (bdist_msi) that both work great on Windows. Plus there are add-ons for other installers such as NSIS and InnoSetup. Please don't forget that setuptools is not distutils, it's just a package extending distutils. If you find bugs related to Windows, please file a bug report. If you have specific proposals for distutils on Windows, you can use the mailing list or send patches to the tracker. The ham/egg ratio on the mailing list tends to be very much on the egg side, so the tracker can help get more attention from folks doing distutils without setuptools. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 07 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Mon, Oct 5, 2009 at 5:11 PM, M.-A. Lemburg <mal@egenix.com> wrote:
The idea of PEP 376 we are working on is to have a unique unified standard for distributions installed in site-packages, instead of the current situation where we have many installation formats. (Distutils pre-Python 2.5, Distutils post-Python2.5, Setuptools self-contained Eggs, ..) because it makes it simple to provide APIs to query what's installed, and ways to uninstall things. That's what I would call the "Missing APIs" to make Distutils a package manager, or at least a basis for package managers. Having an egg installer/uninstaller that works with Setuptools-like self-contained eggs sounds like a package manager system on its own and yet another format. But as far as we went in the discussions for PEP 376, it seemed like a first step would be to work with a single installation format and provides all APIs for it, then to think about having other formats and ways to query them in a second move. That's why I don't think its the right time to add a bdist_egg command in Distutils, until PEP 376 is fully defined (and maybe extended to support several format). Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
Senthil Kumaran wrote:
I don't dislike the format itself, just the tools that are available for using it. We've implemented our own bdist_egg now which doesn't use setuptools and will start to ship eggs in addition to our prebuilt format with the next releases. As time permits, we'll also write an egg installer/uninstaller (one that does only that ;-).
Let's hope not :-) Besides, the discussions should be about the tools used for package distribution - the egg format itself is fine. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
M.-A. Lemburg wrote:
Egg-cellent ;-) Any chance this tool is open source? Better yet, could it make its way into distutils asap? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
mxSetup.py, the module implementing all our distutils extensions, is available in egenix-mx-base which is open source: http://www.egenix.com/products/python/mxBase/ Here's current snapshot: http://downloads.egenix.com/python/egenix-mx-base-3.2.0_20091006.zip or as egg http://downloads.egenix.com/python/egenix_mx_base-3.2.0_20091006-py2.6-linux... Note how the package name is mangled... easy_install requires this. The file name also doesn't tell you that the above is for a UCS2 Python build. Again, easy_install fails with that information added to the "py2.6" version marker. We're still tweaking the implementation a bit, but it's stabilizing rather quickly. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
M.-A. Lemburg wrote:
I have memories of mxBase having a load of other stuff in it too? Would it be possible to split just the distutils extensions into their own package and get that package as an sdist on PyPI? That said, I still think getting the bdist_egg code, at least, into Distutils in the core as soon as possible would be a very good thing. It's kinda odd having the python equivalent of jars or gems only being created by third party software that's no longer maintained...
Surely this stuff all belongs in the static metadata file that keeps on overcomplicating itself in discussions? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
I'll make the argument that feedback is useful, comments are much less so and a lot more work. It would be more useful to allow package users post feedback, visible only to the package maintainer, and also add support for bugtracker links/etc. Is the intention of Pypi really to turn it into a social networking site?
Chris Withers wrote:
Yep, lots of it.
Would it be possible to split just the distutils extensions into their own package and get that package as an sdist on PyPI?
Nope. The main reason for having switched to distributions is to make things easier to manage - both for us and our users.
The complicated stuff does belong somewhere else, but the basic things need to go into the filename - simply because you have to build separate files for each Python build dimension and want to be able to put everything into a single directory or index: * Python version * Architecture/Platform * UCS2/UCS4 E.g. to solve the UCS2/4 part, we had to setup separate PyPI-style index sites. We'd really like to avoid that if possible. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
M.-A. Lemburg wrote:
shame :-(
The complicated stuff does belong somewhere else, but the basic things need to go into the filename
But everyone's basic things are different.
Well yeah, and the only sane way I can think to handle this is to have a metadata file that gets uploaded with each distribution that covers all these things (and the other things that other people need) and then have the index (which would hopefully be PyPI on the whole) be queryable along the lines of "give me a download url for a distribution named X that is for Python 2.6, Win32, UCS4, PostGreSQL 8.5, BlagBlah"... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
The really basic stuff is the same for everyone since it's dictated by the way Python works on computers :-)
So you want the indirection to happen even before fetching the download package ? That's a good idea - and also a lot better than the web page link scanning that setuptools is doing. It goes a bit in the direction of what we had in mind with writing for our clients: a tool that looks at the Python installation and automatically finds/downloads/installs the right package from our website. Only that we wanted to put up a single index file for that tool to use, not one per package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
At 06:03 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
They're not mutually exclusive, btw. More information could be added to the PyPI "Simple" API to include this sort of thing, visible to newer installers and invisible to older ones. The main reason why easy_install has a relatively simple, REST outgoing API is that it allows people to make their own compatible indexes just by throwing some files in a directory and turning on Apache directory indexing. By using a... what do they call it, "microformat"? to mark up other information in the file, it'd still be possible for someone to slap up a web page and use it as a package index.
That'd get a bit big for PyPI, though, with thousands of listed packages. It's already pretty slow whenever somebody miscapitalizes or mis-punctuates a package name and easy_install has to read the "file" that just lists all the package names. That, of course, is more a function of the fact that PyPI's "simple" API doesn't support canonicalization, although I believe certain other PyPI-mirroring and package indexing apps do.
P.J. Eby wrote:
The above was only meant for our eGenix packages, not PyPI. For PyPI the natural answer to this is to use the already existing PyPI XML-RPC interface: http://wiki.python.org/moin/PyPiXmlRpc This would only have to grow a few more fields for the release downloads in order to be able to match the user's Python configuration to the available release downloads. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
At 10:17 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
Yes, but it's not easily duplicated by somebody who's just got a plain ol' web page, nor is it amenable to static page mirroring. A GET-only REST API, on the other hand, is compatible with both.
On Tue, 06 Oct 2009 16:45:29 +0100, Chris Withers <chris@simplistix.co.uk> wrote:
Exactly. I'd like to see that and it sounds like a very simple and reasonable proposal. One could say that much of the setuptools cloud came about because of the lack of the queryable download url. Setuptools does a lot of work here to 'work-around' the ommission on pypi of a package download url. I'm just with you 100% on this... David
David Lyon wrote:
I think you two have missed my email to PJE. In summary: PyPI already does have mechanism for querying download URLs. http://wiki.python.org/moin/PyPiXmlRpc It only lacks some more meta-data that would be required to match up the user's configuration with the one used in the uploaded URLs. And it would be handy to have a mechanism to just upload the URL data rather than the whole package. Looking at distutils' upload command, PyPI currently appears to only support uploads of the package file itself. Basically, most of the mechnisms are already there, they just need some extra care. BTW: Who would I need to contact for the PyPI side to work out an upload_url distutils command ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 08 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Thu, Oct 8, 2009 at 9:35 AM, M.-A. Lemburg <mal@egenix.com> wrote:
BTW: Who would I need to contact for the PyPI side to work out an upload_url distutils command ?
I am not sure to understand. How upload_url will differ from the register command that let you upload metadata at PyPI ? Tarek
Tarek Ziadé wrote:
The register command only uploads the package's meta-data. The upload command uploads a file and registers the file's details with PyPI as well. I'd like to add an upload_url command which only registers a file's details (including the URL, but without the actual file) with PyPI and perhaps extend the number of attributes sent to PyPI with more file configuration information (upload currently only sends the Python version). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 08 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Thu, Oct 8, 2009 at 10:38 AM, M.-A. Lemburg <mal@egenix.com> wrote:
Sounds like an option to be added in upload.
-- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
Tarek Ziadé wrote:
With a little code refactoring that would be possible as well, yes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 08 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Thu, 08 Oct 2009 09:35:57 +0200, "M.-A. Lemburg" <mal@egenix.com> wrote:
Maybe you're right. I'll look into it.
BTW: Who would I need to contact for the PyPI side to work out an upload_url distutils command ?
pypi is on sourceforge... ask to become a developer I guess.. David
David Lyon wrote:
I know that the issue tracker for PyPI is (still) on SF, but development appear to happen elsewhere and I can't find any contact information on the PyPI web pages. Is Richard Jones still working on it ? They I could contact him directly to hash this out. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg <mal@egenix.com> wrote:
Everything is provided here: http://wiki.python.org/moin/CheeseShopDev
Is Richard Jones still working on it ? They I could contact him directly to hash this out.
I think Martin vL is the most active developer at this time. Regards Tarek
Tarek Ziadé wrote:
Thanks for the URL.
Ok, then I'll coordinate with Martin. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 09 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
"Martin v. Löwis" wrote:
Ok, then I'll sign up there. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 10 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
At 03:18 PM 10/6/2009 +0200, M.-A. Lemburg wrote:
Btw, every couple years or so I've sent out a call on the distutils-SIG to try to get consensus on a format for the platform tag information used by setuptools. (The first time was before easy_install even existed.) Unfortunately, it's rare that anybody contributes more than criticism of the existing scheme. The last updates to the scheme were by Mac folks, who at least had a clear vision of what was needed. There's been some win32/win64 discussion in the past, but no proposals or patches of comparable specificity. Linux and other unices haven't had any concrete suggestions at all, AFAICR. Anyway... just saying that if you *have* a concretely implementable proposal about what to do with platform tags, please do share on the distutils-sig. Platform tags are one area that's reasonably easy to upgrade in a backward-compatible-ish way; newer versions of easy_install can still recognize older tags, although new eggs won't be recognized by older installers (forcing people to upgrade setuptools in that case).
P.J. Eby wrote:
Here's a very simple Python version scheme we've been using for years: pyX.X_ucsY with X.X being the major.minor Python version and Y being either 2 or 4 depending on the UCS-build that was used to build the egg. The "_ucsY" part is not needed for pure-Python archives (but it doesn't hurt using it there as well) and also not needed on Windows, since Python is always UCS2 on Windows. easy_install should first look for the full version string and then fall back to the non-UCS one. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 05 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Tue, 06 Oct 2009 13:52:34 -0400, "P.J. Eby" <pje@telecommunity.com> wrote:
Consider the fact that Mac users won't answer or discuss posts by some windows users.. Why do this ? Why stir up platform bias? Fact is Phil, windows users get *turned-away* at the door in distutils... or ignored. Issues can hang around for years. And your post is now asking "why no windows users?" Go figure.. nobody answers them or takes issues seriously. Distutils for windows is very, very dead.. grave-ware in-fact. It should be quite obvious that windows users are forked off.. Why would windows people make proposals when they know it won't go anywhere... David
David Lyon wrote:
Distutils for windows is very, very dead.. grave-ware in-fact.
Now that is not true at all. We have a native Windows installer (bdist_wininst) and an MSI builder (bdist_msi) that both work great on Windows. Plus there are add-ons for other installers such as NSIS and InnoSetup. Please don't forget that setuptools is not distutils, it's just a package extending distutils. If you find bugs related to Windows, please file a bug report. If you have specific proposals for distutils on Windows, you can use the mailing list or send patches to the tracker. The ham/egg ratio on the mailing list tends to be very much on the egg side, so the tracker can help get more attention from folks doing distutils without setuptools. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 07 2009)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Mon, Oct 5, 2009 at 5:11 PM, M.-A. Lemburg <mal@egenix.com> wrote:
The idea of PEP 376 we are working on is to have a unique unified standard for distributions installed in site-packages, instead of the current situation where we have many installation formats. (Distutils pre-Python 2.5, Distutils post-Python2.5, Setuptools self-contained Eggs, ..) because it makes it simple to provide APIs to query what's installed, and ways to uninstall things. That's what I would call the "Missing APIs" to make Distutils a package manager, or at least a basis for package managers. Having an egg installer/uninstaller that works with Setuptools-like self-contained eggs sounds like a package manager system on its own and yet another format. But as far as we went in the discussions for PEP 376, it seemed like a first step would be to work with a single installation format and provides all APIs for it, then to think about having other formats and ways to query them in a second move. That's why I don't think its the right time to add a bdist_egg command in Distutils, until PEP 376 is fully defined (and maybe extended to support several format). Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
participants (9)
-
"Martin v. Löwis" -
Antoine Pitrou -
Arc Riley -
Chris Withers -
David Lyon -
M.-A. Lemburg -
P.J. Eby -
Senthil Kumaran -
Tarek Ziadé