On Fri, Mar 1, 2013 at 11:37 AM, PJ Eby <p...@telecommunity.com> wrote: > On Fri, Mar 1, 2013 at 4:24 AM, M.-A. Lemburg <m...@egenix.com> wrote: >> On 01.03.2013 10:02, Reinout van Rees wrote: >>> On 28-02-13 21:08, holger krekel wrote: >>>>> I have seen that position in this discussion ("I have to upload 120 >>>>> >files per release, so I won't do that", for instance). >>> >>>> haven't seen that. >>> >>> Marc-Andre Lemburg said this, which I took to mean 120 uploads per release: >>> >>> """ >>> However, taking our egenix-mx-base package as example, we have >>> 120 distribution files for every single release. Uploading those >>> to PyPI would not only take long, but also ... >>> """ >> >> Correct, with a total of over 100MB per release. However, the above >> quote is slightly incorrect: I did not say "I won't do that", just >> that there are issues with doing this: >> >> * It currently takes too long uploading that many files to >> PyPI. This causes a problem, since in order to start the upload, >> we have to register the release on PyPI, which tools will then >> immediately find. However, during the upload time, they won't >> necessarily find the right files to download and then fail. > > Actually, easy_install doesn't pay any attention to what releases are > registered. It just looks for primary and secondary links. If there > are links for a version that it can use, it uses it. If it does not > find links for a version, then that version does not exist, as far as > it is concerned. So registering without files is not a problem. > > >> The proposed pull mechanism (see >> http://wiki.python.org/moin/PyPI/DownloadMetaDataProposal) >> would work around this problem: tools would simply go to >> our servers in case they can't find the files on PyPI. > > That proposal is unnecessary, actually. You could *right now* simply > place binary download links (with optional "#md5=...." verification) > in your package's description field, and the moment you registered the > package, existing tools would find those links and download them from > your site. You could then remove your home page and download URLs > from the relevant fields, and place them also in the description. > (easy_install does not follow non-download links within the > description -- i.e., links that don't end in .egg, .tgz, etc. and > don't have an #egg tag.) > > >> * PyPI doesn't allow us to upload two egg files with the same >> name: we have to provide egg files for UCS2 Python builds and >> UCS4 Python builds, since easy_install/setuptools/pip don't >> differentiate between the two variants. > > They can if it's part of the platform string; the catch is that right > now it's not. We'd have to go through an upgrade cycle of the tools > to support that. I need to take a look at what PEP 427 is doing (and > you should too, if you haven't already) to get this part sorted out.
The compatibility tags are specified in http://www.python.org/dev/peps/pep-0425/ and are first used with PEP 427. The scheme defines a tag which is a combination of implementation, abi, and platform tags, and an algorithm for choosing the "most preferred" among the available builds for a particular release of some distribution. The ABI tags are basically abbreviated versions of the tags from http://www.python.org/dev/peps/pep-3149/ and look like "cp32dmu" for a debug, malloc, wide unicode build of CPython 3.2, or just "cp32" for a Python 3.2 with none of those features compiled in. Your package would probably use tags like "cp32-cp32mu-linux_x86_64". Even though PEP 3149 is a Python 3.2 feature, the *PEP 425* ABI tags are supposed to work in the same way with older version of Python, e.g. "py26u" for a Python 2.6 unicode build. _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig