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
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
25 matches
Mail list logo
