[Catalog-sig] PyPI Enhancements (was: permissive trove classification)

Tarek Ziadé ziade.tarek at gmail.com
Sun Jan 6 12:03:39 CET 2008


Thanks for the feedback


"Martin v. Löwis" wrote:
> 
> "when PyPI is down or slow" - I believe I have worked a lot
> and successfully in making sure that this actually doesn't happen.
> For the last several months, PyPI wasn't slow, and it wasn't
> down for any significant period of time.
> 

Yes this was a bit of a shortcut, as I didn't really mean to say that PyPI
is slow.
It works pretty well. But having an alternative server can be useful:

In my company, it happens that the network is really slow, and some timeouts
may occurs when we work on building some software that calls PyPI. These
builds occurs
all the time with the builder we use (zc.buildout). Having an alternative
server that can be located in our network is useful in that case. We could
use some
caching, but a 100% functional PyPI server is a better pick.

The typical configuration is to have a private PyPI -like server that
contains all packages
needed to build our software (public or private packages) and to use PyPI
itself.


"Martin v. Löwis" wrote:
> 
> "several sections" - how do you use it from distutils, or
> setuptools?
> 
> "When a user call register or uplad with such a file, it will be asked
> for each server wheter he wants to perform the action over it."
> I don't understand that sentence. What is "such" a file?
> (wheter->whether, it will -> he will)
> 

When a user call the register or the upload command with such a file, it
will loop through every section, and ask the used at the prompt if he wants
to perform the action over the given server.
I have changed the document to make it clearer. See "How sections in .pypirc
are used"

The iw.dist module implements a prototype of such a change, with two
commands called "mupload"
and "mregister", that are subclasses of setuptools' upload and regsiter at
this time.


"Martin v. Löwis" wrote:
> 
> "Making PyPI permissive" - it's not clear whether you want PyPI to
> store these additional classifiers or not. If PyPI is required
> to store them, be prepared that the changes to PyPI will be
> *very* difficult to implement. I
> 

No, the server wouldn't store them. It will just ignore them. That
would be done by returning a simple warning when a category in 
the received classifiers is unknown.


"Martin v. Löwis" wrote:
> 
> If PyPI is allowed to discard them,
> I see a number of alternatives:
> a) make a list of "extra_classifiers" in setup.py, which a server
>    is free to discard.
> b) give the list of extra classifiers in .pypirc, per server.
>    distutil's register command would then drop all classifiers
>    which are listed as server specific, unless registering with
>    that selected server
> 

An extra_classifiers would be interesting, but I don't think
storing these classifiers on client-side would be maintainable, 
since it's up to the server to make this list evolve.


"Martin v. Löwis" wrote:
> 
> "Providing a base layer". It's not clear to me what that actually
> means. PyPI *does* have a separation of webui and store, so it
> is layered. Not sure what you are asking for.
> 

Yes, that was not clear at all, I included an example the document.
I was just talking about having a separate interface that exposes
the API for the storage and the web interface. This interface
could be used as a common base for all PyPI-like server,
even if they don't use SQL to store data


Regards
Tarek

-- 
View this message in context: http://www.nabble.com/PyPI-Enhancements-%28was%3A-permissive-trove-classification%29-tp14614933p14646918.html
Sent from the Python - catalog-sig mailing list archive at Nabble.com.



More information about the Catalog-SIG mailing list