I've updated distlib[1] with a new, high-level API for accessing PyPI. While the
existing locators API deals with locating distributions already uploaded to
PyPI, the index API allows the following:
* Registering a project on PyPI
* Uploading source and binary distributions to PyPI (incl.
On Sun, Feb 3, 2013 at 6:37 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've updated distlib[1] with a new, high-level API for accessing PyPI. While
the
existing locators API deals with locating distributions already uploaded to
PyPI, the index API allows the following:
* Registering a
Nick Coghlan ncoghlan at gmail.com writes:
Very cool, but would it be possible to expand the class name to
something like PackageIndex? Index is an overloaded word,
Good suggestion - done. I also added a method to verify signatures; though this
is not strictly related to index operations,
On 16.10.2012, at 20:52, Éric Araujo mer...@netwok.org wrote:
Le 16/10/2012 14:45, Daniel Holth a écrit :
How could I have forgotten about draft PEP 390:
This is obsolete and should not be implemented.
Hi Éric,
Excuse my questions in case that information is somewhere noted but could you
Le 16/10/2012 14:45, Daniel Holth a écrit :
How could I have forgotten about draft PEP 390:
This is obsolete and should not be implemented.
Regards
___
Distutils-SIG maillist - Distutils-SIG@python.org
On Sat, Oct 13, 2012 at 8:16 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
There's plenty more work to do - if there's mileage in this idea, instead of
returning Metadata and lists of dicts, Distribution instances can be returned
which can be queried for dependencies in a more natural way. At
Daniel Holth dholth at gmail.com writes:
When you are using setuptools, setup.py can be used to generate
declarative metadata with the command python setup.py egg_info. You
can add --egg-base dir to put the static metadata in a different
directory. Setuptools even makes it easy to add new
On Mon, Oct 15, 2012 at 2:41 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Daniel Holth dholth at gmail.com writes:
When you are using setuptools, setup.py can be used to generate
declarative metadata with the command python setup.py egg_info. You
can add --egg-base dir to put the static
I've updated distlib with an experimental API for locating distributions. A
locator is just something whose get_project method you invoke with a project
name such as flask or sqlalchemy, and it returns a dictionary whose keys
are versions of the project which were located, and the corresponding
On Tue, Oct 9, 2012 at 7:28 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I don't believe that wheels are meant to be directly importable, but I could
be wrong about that. I am not sure why callee dependencies need to be
transparently met by distributions not on sys.path; Broadly speaking, and
On Tue, Oct 9, 2012 at 7:53 PM, Daniel Holth dho...@gmail.com wrote:
would also like to be able to store my installed package database in
sqlite3 by implementing an appropriate distlib/pkg_resources backend
and defining a standard post-(un)install index this new package hook
but I doubt I will
On 10 October 2012 23:15, PJ Eby p...@telecommunity.com wrote:
However, for the application platform plugins use case, wheels can
potentially be quite awesome, because you can build one fat wheel for
all your supported platforms. We don't want to inlcude .pyc files
for all the Pythons you
PJ Eby pje at telecommunity.com writes:
I'm not saying distlib must support all these plugin usecases
*itself*, but if it solves its chosen usecases in a way that can't be
*adapted by others* to handle the app platform use cases, then there's
not going to be an appealing alternative to
On Wed, Oct 10, 2012 at 6:15 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Oct 9, 2012 at 7:53 PM, Daniel Holth dho...@gmail.com wrote:
would also like to be able to store my installed package database in
sqlite3 by implementing an appropriate distlib/pkg_resources backend
and defining a
On Mon, Oct 8, 2012 at 5:14 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
What do *you* mean by entry point? My understanding is that it represents the
start of some executable code. Wikipedia:
In computer programming, an entry point is a memory address, corresponding
to a
point in the
PJ Eby pje at telecommunity.com writes:
In pkg_resources, entry points are references to any importable
object. They don't have to be callables.
Note, however, that if you load an entry point which is a module, then
of course the module code will be executed as a side-effect, so
On Tue, Oct 9, 2012 at 5:45 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Clearly, distlib can't do things exactly
the way they're done in pkg_resources and setuptools, since those are not
considered suitable to go into the stdlib,
The two aren't 100% connected, even assuming the antecedent
On Fri, Oct 5, 2012 at 2:38 PM, Paul Moore p.f.mo...@gmail.com wrote:
That's a good point. Actually, writing a local PyPI server is much
easier if all you have to implement is the simple static page
interface. So I take back some of my objection - both XML-RPC and the
static page interface
PJ Eby pje at telecommunity.com writes:
More to the point, though, if it's not possible for someone to create
a wrapper to reimplement these portions of the pkg_resources API, then
it's going to be harder to get people to port their code.
I will give some thought to migration concerns. I'm
On Tue, Oct 9, 2012 at 5:45 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
PJ Eby pje at telecommunity.com writes:
In pkg_resources, entry points are references to any importable
object. They don't have to be callables.
Note, however, that if you load an entry point which is a module, then
On Sat, Oct 6, 2012 at 3:44 AM, Antonio Cavallo a.cava...@cavallinux.eu wrote:
Here few lesson learnt using rpm and python at fairly large scale
(http://download.opensuse.org/repositories/home:/cavallo71:/opt-python-interpreters)
project of mine I wish could be of some help in thinking of a
On Mon, Oct 8, 2012 at 2:05 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've now updated distlib to include equivalent functionality for
pkg_resources'
entry points. There is no ability to install packages on-demand via
require()
functionality, but distributions are able to register
On Mon, Oct 8, 2012 at 9:34 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Registry of what ever you like - pointers to data, perhaps. Any use of the
registry, just like entry points, is a matter of convention between consenting
/ cooperating developers and their applications/libraries, or am I
Lennart Regebro regebro at gmail.com writes:
IIUC, you're allowed to just define a module or package without the
attributes appearing after the :
Right, but isn't that then an entry point?
How is it an entry point? Perhaps I'm misunderstanding what an entry point is,
but to my mind it's
Daniel Holth dholth at gmail.com writes:
I would prefer to keep the filename the same as long as the format is
the same.
See my comments about read_registry and write_registry methods in Distribution
(in response to Lennart's post).
In other words, it is a hassle and the feature is the same.
On 5 Oct 2012, at 20:28, Stanley A. Klein wrote:
I assume that by an installer you mean the combination of package
building (done by e.g., rpmbuild) and installation (done by e.g., rpm or
yum).
Hi,
I think you've hit the jackpot here…
Here few lesson learnt using rpm and python at fairly
On 05.10.2012 19:24, Paul Moore wrote:
On 5 October 2012 17:04, Daniel Holth dho...@gmail.com wrote:
~1300 of the ~2 packages on pypi have trouble using setup.py as
their build system / metadata source format.
That's interesting information. Do you know in what way they have
trouble
Matthias Klose doko at ubuntu.com writes:
PS: are there really ~2 packages on pypi, or do you count old versions
too?
Not counting old versions, my current list of packages where an archive is
hosted
on PyPI numbers a little under 18,000. While not bang up to date, it's unlikely
to
On 10/5/12 12:28 AM, Vinay Sajip wrote:
I've updated distlib as follows:
1. I've added support for the equivalent of pkg_resources.resource_filename
for returning a true filesystem path for a resource. I've added info about
this in the Distlib's design document, though the reference API
Daniel Holth dholth at gmail.com writes:
I still like the mimic os.listdir but with an additional package
argument API because it has fewer parts. Is there a reason why we
can't just fix pkgutil? It is probably much easier to do it in
distlib.
Sorry, I didn't get what you meant in the
On 5 October 2012 10:27, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
+1 on this. Can you share a little more on your hint idea? I have a
specific use case in mind, and would like to know if it's covered.
It's an intranet webpage that hosts packages in a very odd format,
unfortunately, so I
Tarek Ziadé tarek at ziade.org writes:
I like the idea of having a main section to play with the tools, people
can invoke with -m
I don't think its a bad idea to have it in each module, like what Python
does
for SimpleHTTPServer or json.tools
I've no problem with having a if __name ==
I mean should there be a pkgutil.pkg_listdir, etc. to accompany pkgutil.get_data
Daniel Holth
On Oct 5, 2012, at 5:32 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Daniel Holth dholth at gmail.com writes:
I still like the mimic os.listdir but with an additional package
argument API
On 10/5/12 12:19 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
I like the idea of having a main section to play with the tools, people
can invoke with -m
I don't think its a bad idea to have it in each module, like what Python
does
for SimpleHTTPServer or json.tools
I've no
Check out the reasonably modular and cleanly written pyg installer.
https://github.com/rubik/pyg/
It has its own independent package database / metadata parser.
https://github.com/rubik/pkgtools/blob/master/pkgtools/pkg.py
It has a pypi interface too.
Daniel Holth dholth at gmail.com writes:
Is this supposed to go into the stdlib? Simple reference
implementations (wsgiref) fare better there than frameworks
(distutils). The pluggable installer metaframework belongs on pypi.
I'm thinking of distlib as a library rather than a framework.
On 5 October 2012 14:47, Daniel Holth dho...@gmail.com wrote:
Is this supposed to go into the stdlib? Simple reference
implementations (wsgiref) fare better there than frameworks
(distutils). The pluggable installer metaframework belongs on pypi.
I disagree. Having an installer depend on
Paul Moore p.f.moore at gmail.com writes:
No-one could try to claim that the sort of web-scraping that
easy_install/pip does is a simple reference implementation, either.
If you take that viewpoint, I'd say the stdlib implementation should
*only* use the XMLRPC interface to PyPI. Code to use
On 5 October 2012 15:37, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
PS If you want to start over-engineering the flexibility, users should
have a way of choosing whether to use the webscraper or XMLRPC
interfaces to PyPI. The former finds more packages (as I understand
it) whereas the latter
, October 5, 2012 6:00 am, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Date: Thu, 4 Oct 2012 22:28:01 + (UTC)
From: Vinay Sajip vinay_sa...@yahoo.co.uk
To: Distutils-Sig@Python.Org
Subject: [Distutils] distlib updated - comments sought
I've updated distlib as follows:
1. I've added
On Fri, Oct 5, 2012 at 11:39 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
The first ones are fine, as they point to files. The second is often a
file, and seems to frequently duplicate the first. I'm not sure how
useful it is. The final one often
Stanley A. Klein sklein at cpcug.org writes:
I looked at the documentation and can't completely follow what you are
doing, although I was told in another email that the issue I raised was
being addressed in pkg_resources.
The goal of distlib is to provide a library of low-level functions
Daniel Holth dholth at gmail.com writes:
IIRC the most practical limitation is that the XML-RPC interface
doesn't exist on the mirrors.
Of course. It's easier to replicate a static website than an XML-RPC server
to Web Scale ;-), but I presume it's only a question of hosting resources and
On Fri, Oct 5, 2012 at 10:23 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 5 October 2012 14:47, Daniel Holth dho...@gmail.com wrote:
PPS If my locator interface ever matures enough, I'm happy to release
it on PyPI. But I don't want to compete with Vinay or a stdlib
implementation, so I'd
On Fri, Oct 5, 2012 at 1:24 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 5 October 2012 17:04, Daniel Holth dho...@gmail.com wrote:
~1300 of the ~2 packages on pypi have trouble using setup.py as
their build system / metadata source format.
That's interesting information. Do you know in
Paul Moore p.f.moore at gmail.com writes:
- a reasonable proportion of distlib offers alternatives to the
pkg_resources code, and more could be added.
The next thing for me to look at is entry points, which should be relatively
straightforward to implement.
Regards,
Vinay Sajip
On 5 October 2012 16:40, Daniel Holth dho...@gmail.com wrote:
Well, XML-RPC is of course preferable; the current code in distlib is just
whatever I copied across from packaging, but the next step will be to look
at the releases which are available from the different sources (XML-RPC,
PyPI
Daniel Holth dholth at gmail.com writes:
I'm basing this only on Vinay's numbers of
how-many-packages-can-generate-a-yaml. It's probably mostly packages
that import something he didn't have installed inside setup.py, but I
don't have a good way to find out exactly what is wrong with each one.
On Fri, Oct 5, 2012 at 2:40 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Daniel Holth dholth at gmail.com writes:
I'm basing this only on Vinay's numbers of
how-many-packages-can-generate-a-yaml. It's probably mostly packages
that import something he didn't have installed inside setup.py,
(UTC)
From: Vinay Sajip vinay_sa...@yahoo.co.uk
To: Distutils-Sig@Python.Org
Subject: Re: [Distutils] distlib updated - comments sought
Stanley A. Klein sklein at cpcug.org writes:
I looked at the documentation and can't completely follow what you are
doing, although I was told in another
On 5 October 2012 20:28, Stanley A. Klein skl...@cpcug.org wrote:
What I didn't notice in the distlib documentation were low level functions
that would facilitate the allocation of Pypi files/directories to target
files/directories to help in preparation of the rpm spec.
While I'm not
On Fri, Oct 5, 2012 at 3:28 PM, Stanley A. Klein skl...@cpcug.org wrote:
The issue I had raised was attention to the needs of Linux packaging and
the Filesystem Hierarchy Standard, and apparently that is under
consideration.
The response I received (from Daniel Holth dho...@gmail.com) said in
I've updated distlib as follows:
1. I've added support for the equivalent of pkg_resources.resource_filename
for returning a true filesystem path for a resource. I've added info about
this in the Distlib's design document, though the reference API has not
been fully updated - I thought
On Thu, Oct 4, 2012 at 6:28 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've updated distlib as follows:
1. I've added support for the equivalent of pkg_resources.resource_filename
for returning a true filesystem path for a resource. I've added info about
this in the Distlib's design
On 09/27/2012 06:48 PM, Vinay Sajip wrote:
Georg Brandl g.brandl at gmx.net writes:
No, but I can see why you want it there, and I for one have no problems
creating and maintaining that repository.
Great. Thanks!
And we'd like to keep it that way.
:-)
Are you sure you're not
Georg Brandl g.brandl at gmx.net writes:
I've cloned the bitbucket.org/vinay.sajip/distlib repo to
hg.python.org/distlib.
Thank you very much.
At the moment no hooks are set up; let me know if you want e.g. email
notification, CIA or roundup integration.
Are the coding style (whitespace)
Daniel Holth dholth at gmail.com writes:
I feel it is necessary to implement pkg_resources.py on top of any new
API. For example just monkey-patch pkg_resources with the parts you've
implemented, or implement the new API by calling pkg_resources. It
would be a very healthy exercise to see
I've updated distlib[1] with a scripts API - functionality for installing
scripts.
The design and implementation covers shebang adjustment and optional native
Windows executable installation (like setuptools).
The update includes:
A short tutorial showing how to use the API. [2]
A discussion of
Not bad. The wheel installer could probably use the scripts wrapper.
On Thu, Sep 27, 2012 at 6:43 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've updated distlib[1] with a scripts API - functionality for installing
scripts.
The design and implementation covers shebang adjustment and
Daniel Holth dholth at gmail.com writes:
Not bad. The wheel installer could probably use the scripts wrapper.
Good to know, thanks. I noticed that the PEP referred to script installation but
didn't notice it in the wheel implementation.
Regards,
Vinay Sajip
Daniel Holth dholth at gmail.com writes:
What you can do with pkgutil is call
pkgutil.iter_importer_modules.register(importer, function) so that
your new importer works with iter_modules. Unfortunately even though
it implements most of what you would need to listdir() a zip file,
using
On Thu, Sep 27, 2012 at 9:14 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I haven't defined any new importers. In terms of listing a whole zip's
contents,
that's not part of the idea of a resource: you need to know what resource you
want, before you can get it, at least at the top level. Of
On 9/26/12 11:58 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
On a side note, since these are the original modules that were taking
out of Python's packaging implementation,
I don't think you can copyright them under your name like what I have
seen in setup.py
AFAIK I've only
On 27 September 2012 15:01, Tarek Ziadé ta...@ziade.org wrote:
I think it's perfectly fine to have hg.python.org/distlib and do what you
described.
It can mature there - it does not bother cpython or other repositories.
One advantage of distlib being on bitbucket is that anyone can fork it
On 9/27/12 4:22 PM, Paul Moore wrote:
On 27 September 2012 15:01, Tarek Ziadé ta...@ziade.org wrote:
I think it's perfectly fine to have hg.python.org/distlib and do what you
described.
It can mature there - it does not bother cpython or other repositories.
One advantage of distlib being on
(Sorry, meant to post to the list)
On 27 September 2012 15:26, Tarek Ziadé ta...@ziade.org wrote:
But then, unless I am mistaken, you have to ask each contributor to sign the
agreement to avoid any issue the day it goes into Python.
TBH, I'm not sure. I've contributed some patches to Python
On 9/27/12 4:40 PM, Paul Moore wrote:
(Sorry, meant to post to the list)
On 27 September 2012 15:26, Tarek Ziadé ta...@ziade.org wrote:
But then, unless I am mistaken, you have to ask each contributor to sign the
agreement to avoid any issue the day it goes into Python.
TBH, I'm not sure.
Le jeudi 27 septembre 2012 à 16:01 +0200, Tarek Ziadé a écrit :
On 9/26/12 11:58 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
On a side note, since these are the original modules that were taking
out of Python's packaging implementation,
I don't think you can copyright
On 9/27/12 4:28 PM, Antoine Pitrou wrote:
Le jeudi 27 septembre 2012 à 16:01 +0200, Tarek Ziadé a écrit :
On 9/26/12 11:58 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
On a side note, since these are the original modules that were taking
out of Python's packaging
Tarek Ziadé tarek at ziade.org writes:
There are two of us maintaining hg.python.org: Georg and I. So, I don't
know about Georg, but I don't want to maintain repositories for every
third-party library that might one day become part of Python. OTOH, if
Georg wants to handle it, then fine
On 9/27/12 5:40 PM, Antoine Pitrou wrote:
Tarek Ziadé tarek at ziade.org writes:
There are two of us maintaining hg.python.org: Georg and I. So, I don't
know about Georg, but I don't want to maintain repositories for every
third-party library that might one day become part of Python. OTOH, if
On 09/27/2012 05:49 PM, Tarek Ziadé wrote:
On 9/27/12 5:40 PM, Antoine Pitrou wrote:
Tarek Ziadé tarek at ziade.org writes:
There are two of us maintaining hg.python.org: Georg and I. So, I don't
know about Georg, but I don't want to maintain repositories for every
third-party library that
Tarek Ziadé tarek at ziade.org writes:
I would just leave it in hg.python.org and drop any single author
header, and
have the project driven by the community under the PSF governance.
If we want to thank contributors like you or me or anyone that helped in
this code
base we can always
Georg Brandl g.brandl at gmx.net writes:
No, but I can see why you want it there, and I for one have no problems
creating and maintaining that repository.
Great. Thanks!
And we'd like to keep it that way.
:-)
Are you sure you're not overreacting?
All that Antoine is saying is
On 9/27/12 6:37 PM, Georg Brandl wrote:
On 09/27/2012 05:49 PM, Tarek Ziadé wrote:
On 9/27/12 5:40 PM, Antoine Pitrou wrote:
Tarek Ziadé tarek at ziade.org writes:
There are two of us maintaining hg.python.org: Georg and I. So, I
don't
know about Georg, but I don't want to maintain
Tarek Ziadé tarek at ziade.org writes:
I've also said that I believed that it's simpler to include back wrt
licensing if it's a code base
that's under the contributors agreement.
What does that have to do with hg.p.o? You can ask contributor agreements if
your code is hosted on bitbucket.
On 9/28/12 12:55 AM, Antoine Pitrou wrote:
Last but not least, distlib is the plan forward endorsed by python-dev,
Is it? I haven't seen a PEP or an official decision about that. Just because
someone proposed it on a mailing-list doesn't mean it is endorsed by
python-dev.
We discussed about
Tarek Ziadé tarek at ziade.org writes:
On 9/28/12 12:55 AM, Antoine Pitrou wrote:
Last but not least, distlib is the plan forward endorsed by python-dev,
Is it? I haven't seen a PEP or an official decision about that. Just because
someone proposed it on a mailing-list doesn't mean it is
On 9/23/12 5:57 PM, Vinay Sajip wrote:
I've updated distlib[1] with a resources API - functionality for accessing data
files co-located with code in Python packages. This is missing from the stdlib
and currently people use pkg_resources to achieve this.
The design and implementation allows for
Tarek Ziadé tarek at ziade.org writes:
On a side note, since these are the original modules that were taking
out of Python's packaging implementation,
I don't think you can copyright them under your name like what I have
seen in setup.py
AFAIK I've only added my copyright to the individual
If distlib doesn't make it into the stdlib, it'll be dead in the water anyway,
as the purpose of it is to find a common underpinning in the stdlib that
higher
level tools can use, to achieve interoperability and consistency across
different packaging tools. I will be adding more features as
I've updated distlib[1] with a resources API - functionality for accessing data
files co-located with code in Python packages. This is missing from the stdlib
and currently people use pkg_resources to achieve this.
The design and implementation allows for accessing resources from packages
82 matches
Mail list logo
