Re: [Python-Dev] Status of packaging in 3.3
On 20/06/2012 14:53, Nick Coghlan wrote: 3.4 PEP: Standard library package downloader (pysetup) -- # Amongst other things, this needs to have a really good security story (refusing to install unsigned packages by default, etc) packaging.depgraph — Dependency graph builder packaging.pypi — Interface to projects indexes packaging.pypi.client — High-level query API packaging.pypi.base — Base class for index crawlers packaging.pypi.dist — Classes representing query results packaging.pypi.simple — Crawler using the PyPI “simple” interface packaging.pypi.xmlrpc — Crawler using the PyPI XML-RPC interface packaging.tests.pypi_server — PyPI mock server packaging.fancy_getopt — Wrapper around the getopt module # Why does this exist? I'm okay and willing to work on this part. I started a full review of the code I wrote years ago, and which clearly needs some cleaning. Alos, I'm not sure to understand what having a PEP to manage this means: should I describe all the API in a text document (with examples) so we can discuss this and validate before doing the changes/cleanings to the API? Alexis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of packaging in 3.3
On 20/06/2012 13:31, Tarek Ziadé wrote: packaging.metadata is the implementation of all metadata versions. standalone too. packaging.pypi is the PyPI crawler, and has fairly advanced features. I defer to Alexis to tell us is it's completely stable packaging.pypi is functionally working but IMO the API can (and probably should) be improved (we really lack feedback to know that). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of packaging in 3.3
Le mer. 20 juin 2012 15:28:56 CEST, Nick Coghlan a écrit : There would be two main parts to such a PEP: - defining the command line interface and capabilities (pysetup) - defining the programmatic API (packaging.pypi and the dependency graph management) Okay. I don't think that the command line has anything to do with packaging.pypi and dependency management tools. One is dealing with the hole cli for different tings (install / remove / search etc.) while the other one is only how to communicate with the indexes and build dependency graphs from there. We probably should put the cli part in a separate PEP, as the scopes aren't the same that the ones I see for packaging.pypi / depgraph I would suggest looking at PEP 405 (venv) and PEP 397 (Windows launcher) to get an idea of the kind of content that might be appropriate. It's definitely not necessary to reproduce the full API details verbatim in the PEP text - it's OK to provide highlights and point to a reference implementation for the full details. Thanks for the pointers, will read them and try to come back with a PEP proposal. Alexis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging documentation and packaging.pypi API
Le mer. 20 juin 2012 18:45:23 CEST, Paul Moore a écrit : Thanks - as you say, it's not so much the actual problem as the principle of what the packaging API offers that matters here. Although it does make a good point - to what extent do the packaging APIs draw on existing experience like that of pip? Given that tools like pip are used widely to address real requirements, it would seem foolish to *not* draw on that experience in designing a stdlib API. IIRC, pip relies nly onthe XML/RPC API to get information about the distributions from the cheeseshop. the code that's in packaging.pypi was built with the implementation in setuptools in mind, so we keep compatibility with setuptools easy_install. But this is for the internal implementation. You're right and I will have a deep look at what the API in pip looks like when it comes to download packages from PyPI. That is, this leverages one question more on my side: was/is pip intended to be used as a library rather than as a tool / are there some people that are actually building tools on top of pip this way? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging documentation and packaging.pypi API
On 20/06/2012 17:29, Paul Moore wrote:
I wasn't aware of this - I've had a look and my first thought is that
the documentation needs completing. At the moment, there's a lot that
isn't documented, and we should avoid getting into the same situation
as with distutils where people have to use undocumented APIs to get
anything done. There are a lot of examples, but not so much formal API
documentation.
So that's something we definitely want to fix. The code is heavily annotated,
and this had been made to generate the documentation automatically with sphinx
in the first time, so… that would make no sense to not make it.
This is for the format API documentation, which seems to be easy to hook to
sphinx.
I'll also review all the documentation there to make sure that it perfectly makes sense.
As a specific example, one thing I would like to do is to be able to
set up a packaging.pypi client object that lets me query and download
distributions. However, rather than just querying PyPI (the default)
I'd like to be able to set up a list of locations (PyPI, a local
server, and maybe some distribution files stored on my PC) and combine
results from all of them. This differs from the mirror support in that
I want to combine the lists, not use one as a fallback if the other
doesn't exist. From the documentation, I can't tell if this is
possible, or a feature request, or unsupported... (Actually, there's
not even any documentation saying how the URL(s) in index_url should
behave, so how exactly do I set up a local repository anyway...?)
that's not something possible out of the box using the crawler the way
they are defined (iow, that's not one supported use case), *but* it's
possible to make a class on top of the existing ones which could provide
this kind of fallback feature. I'm not sure that we want or don't want
that to be a part of packaging.pypi, but that's definitely something
that this API makes possible without too much trouble.
On a similar note, at some point, crawler.get_releases('pywin32')
needs to work. I believe the issue here is technically with pywin32,
which uses non-standard version numbers (214) and is hosted externally
(Sourceforge) but I'd expect that packaging.pypi should be able to
access anything that's on PyPI, even if other APIs like
packaging.version can't deal with them.
If this is not working / following the links that are present in the
cheeseshp then this should be considered a bug.
Ideally, these would be simply things I'd raise as issues on
bugs.python.org. But as things stand, such issues aren't getting
fixed, and we don't move forward. And without the documentation to
back up a debate, it's hard to argue X is a bug, Y is a feature
request, Z is behaving correctly.
Alright, so this is a true documentation issue. I will make it clearer
what packaging.pypi makes and doesn't make possible.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging documentation and packaging.pypi API
Hi Carl, Thanks for clarifying this. This means that indeed we have the same goals. I'll have a closer look at the internal pip APIs, as they are probably really useful and already used in production environment :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Packaging and setuptools compatibility
Hi folks, I have this in my mind since a long time, but I didn't talked about that on this list, was only writing on distutils@ or another list we had for distutils2 (the fellowship of packaging). AFAIK, we're almost good about packaging in python 3.3, but there is still something that keeps bogging me. What we've done (I worked especially on this bit) is to provide a compatibility layer for the distributions packaged using setuptools/distribute. What it does, basically, is to install things using setuptools or distribute (the one present with the system) and then convert the metadata to the new one described in PEP 345. A few things are not handled yet, regarding setuptools: entrypoints and namespaces. I would like to espeicially talk about entrypoints here. Entrypoints basically are a plugin system. They are storing information in the metadata and then retrieving them when needing them. The problem with this, as everything when trying to get information from metadata is that we need to parse all the metadata for all the installed distributions. (say O(N)). I'm wondering if we should support that (a way to have plugins) in the new packaging thing, or not. If not, this mean we should come with another solution to support this outside of packaging (may be in distribute). If yes, then we should design it, and probably make it a sub-part of packaging. What are your opinions on that? Should we do it or not? and if yes, what's the way to go? -- Alexis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Rights on the tracker
Hi python-devs, I'm currently working on distutils2, and I'm trying to stop having different informations in different places. This means using the bugs.python.org bugtracker, instead of some weird TODO-lists in the bitbucket wiki. Two requests then: * Is it possible to give me the rights to edit the reports for the distutils2 component ? * Is it possible to automatically be in the noisy list for distutils2' bug reports ? Tarek co-opts this. My roundup username is alexis. Thanks, Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rights on the tracker
Le 13/02/2011 15:40, Terry Reedy a écrit : Do you meant that Tarek supports or approves of this? (Co-opt means something rather different in English.) Sorry, I mean that Tarek approves that :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rights on the tracker
Le 13/02/2011 16:12, Éric Araujo a écrit : Hi, I’ve wanted to move our TODO wiki page to the bug tracker for months, thanks for doing it! Auto-nosy is useful to catch new bugs; for existing bugs, instead of adding yourself manually to each one and trigger not-so-useful email, a tracker admin could add you automatically. I’ve asked on http://psf.upfronthosting.co.za/roundup/meta/issue362 Great, thanks for that :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rights on the tracker
Le 13/02/2011 23:16, Antoine Pitrou a écrit : On Sun, 13 Feb 2011 14:47:01 + Alexis Métaireau ale...@notmyidea.org wrote: * Is it possible to give me the rights to edit the reports for the distutils2 component ? Done. Actually, you have general developer rights, since there doesn't seem to be a way (in the GUI) to restrict those to a specific component. Thanks ! Someone else with the right knowledge and power will have to do that. Okay, there is an issue on the tracker's tracker, as Éric told. Cheers, Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils2 scripts
Le 10/08/2010 05:25 PM, Tarek Ziadé a écrit : On Fri, Oct 8, 2010 at 5:53 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Fri, Oct 08, 2010 at 05:12:44PM +0200, Antoine Pitrou wrote: ... pysetup is shorter Let's use pysetup ! +1 on pysetup. Reusing the well known setup and adding py as a prefix will avoid any conflict. ... I won't bikeshed as long as we stay away from conflicting names. +1. So. Let's add pysetup in distutils2, that will be installed as a classical script. Once we move distutils2 back in the stdlib, it will be provided in Python's bin dir, so people will have the same pysetup name everywhere, Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils2 scripts
Le 10/08/2010 04:31 PM, Jon Ribbens a écrit : On Fri, Oct 08, 2010 at 11:04:35AM -0400, Toshio Kuratomi wrote: In the larger universe of programs, it might make for more intuitive remembering of the command to use a prefix (either py or python) though. python-setup is a lot like python setup.py pysetup is shorter pyegg is even shorter :-) I'd just like to say pypackage again. pypackage install thingy pypackage remove thingy pypackage update thingy Btw, we are not talking about packages, as packages are already used in the python concepts (See http://guide.python-distribute.org/glossary.html) So, it would be better to have something like pydist, but seems to be less obvious than pysetup. Alexis etc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/alexis%40notmyidea.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Released: Python 2.6.6
Le 08/25/2010 05:32 PM, Éric Araujo a écrit : I think that the most important release is docs.python.org/2.6, regardless of python.org/OS-specific downloadable doc packages. If people do like haypo and use the most recent docs instead of the version-specific ones, there’s indeed no need to bother with porting doc fixes and improvements. If people use docs.py.org/2.6 as a reference for some years while 2.7 is not on their systems, it may be worthwhile to keep updating those docs. We can also, recommend to always rely on the last version somewhere, if it's the best way to go. This way, we can avoid those questions in the future. I like how the django project present their documentation: there is a little informational text at the head of each doc, saying that you're not browsing the most up-to-date documentation, you can find the last one here; maybe can we do a similar thing for the python doc ? Regards, Alexis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
