On Tue, 13 Oct 2009 11:33:26 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
The first one who mentioned the idea was Eric IIRC, then Matthias and
Tres worked on it.
Fine. They've been awfully quiet on distutils-sig lately :-)
But who cares ? I am not claiming any ownership on ideas. I am
2009/10/14 David Lyon david.l...@preisshare.net:
However, you are correct about proof of concept code, and in some
respects that's the easy part. I will start work on that immediately.
My suggestion is that once you have a revised PEP that includes some
proof of concept
code with less
David Lyon wrote:
What's a few thousand lines of code between friends..
I think that's some quite tough thousand lines, though. You have to know
a lot about the different platforms, and in my experience at least,
designing a good tool and API around this kind of problems is hard.
The good news
David Lyon wrote:
On Tue, 13 Oct 2009 11:33:26 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
The first one who mentioned the idea was Eric IIRC, then Matthias and
Tres worked on it.
Fine. They've been awfully quiet on distutils-sig lately :-)
Not so!
I just happen to be the one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
Here's a summary of my take on the discussion thus far:
- - There's been some discussion of terminology, based on which I'm
proposing the file be called REQUESTED, and the Distribution boolean
attribute be .requested. I've updated the demo
kiorky a écrit :
[]
This may be quite current even if it's not a good habit to have circular
dependencies between distributions.
Imagine that.
B(0.7) - A(0.6).
A(0.6) - B(0.7).
Can i have the same namespace ns shared between the twice distributions with
both the setuptools
On Wed, Oct 14, 2009 at 4:19 PM, kiorky kio...@cryptelium.net wrote:
kiorky a écrit :
[]
This may be quite current even if it's not a good habit to have circular
dependencies between distributions.
Imagine that.
B(0.7) - A(0.6).
A(0.6) - B(0.7).
Can i have the same namespace ns
2009/10/14 kiorky kio...@cryptelium.net:
This may be quite current even if it's not a good habit to have circular
dependencies between distributions.
Imagine that.
B(0.7) - A(0.6).
A(0.6) - B(0.7).
I don't think that's a problem, although I can't see why you would
need it in this case.
Tarek Ziadé a écrit :
On Wed, Oct 14, 2009 at 4:19 PM, kiorky kio...@cryptelium.net wrote:
kiorky a écrit :
[]
This may be quite current even if it's not a good habit to have circular
dependencies between distributions.
Imagine that.
B(0.7) - A(0.6).
A(0.6) - B(0.7).
Can i have the
Lennart Regebro a écrit :
2009/10/14 kiorky kio...@cryptelium.net:
This may be quite current even if it's not a good habit to have circular
dependencies between distributions.
Imagine that.
B(0.7) - A(0.6).
A(0.6) - B(0.7).
I don't think that's a problem, although I can't see why you
2009/10/14 kiorky kio...@cryptelium.net:
That's not what said the PEP (IOW what i had understood of)
Oh, you don't *use* it the same way, no, but I assumed that the
internal mechanisms would be similar. Maybe I was wrong.
--
Lennart Regebro: Python, Zope, Plone, Grok
I want when i import ns.foo that it works in every module i have on sys.path no
matter which namespace implementation both packages use.
Lennart Regebro a écrit :
2009/10/14 kiorky kio...@cryptelium.net:
That's not what said the PEP (IOW what i had understood of)
Oh, you don't *use* it the
2009/10/14 kiorky kio...@cryptelium.net:
I want when i import ns.foo that it works in every module i have on sys.path
no
matter which namespace implementation both packages use.
Yes, otherwise namespace packages it would rather pointless. :)
--
Lennart Regebro: Python, Zope, Plone, Grok
Lennart Regebro a écrit :
2009/10/14 kiorky kio...@cryptelium.net:
I want when i import ns.foo that it works in every module i have on sys.path
no
matter which namespace implementation both packages use.
Yes, otherwise namespace packages it would rather pointless. :)
You say yes but it
2009/10/14 kiorky kio...@cryptelium.net:
Lennart Regebro a écrit :
2009/10/14 kiorky kio...@cryptelium.net:
I want when i import ns.foo that it works in every module i have on
sys.path no
matter which namespace implementation both packages use.
Yes, otherwise namespace packages it would
from [1]
Likewise, setuptools supports inspecting zip files, and supports adding portions
to its _namespace_packages variable, whereas pkgutil doesn't
[1] - http://www.python.org/dev/peps/pep-0382/
Lennart Regebro a écrit :
2009/10/14 kiorky kio...@cryptelium.net:
Lennart Regebro a écrit :
On Wed, Oct 14, 2009 at 2:46 PM, Eric Smith e...@trueblade.com wrote:
ideas here because I am maintaining Distutils so I'll be the one will
apply the changes there.
Sure. Well collect is a word that means different things to different
people. I'd suggest some caution with using that word
2009/10/14 kiorky kio...@cryptelium.net:
from [1]
Likewise, setuptools supports inspecting zip files, and supports adding
portions
to its _namespace_packages variable, whereas pkgutil doesn't
Yes?
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14
Lennart Regebro a écrit :
2009/10/14 kiorky kio...@cryptelium.net:
from [1]
Likewise, setuptools supports inspecting zip files, and supports adding
portions
to its _namespace_packages variable, whereas pkgutil doesn't
Yes?
There is one obvious incompatibility maybe there will be
Lennart Regebro a écrit :
2009/10/14 kiorky kio...@cryptelium.net:
There is one obvious incompatibility maybe there will be others with the
future
implementations.
It's again an incompatibility in how your package makes something be a
namespace package. Not an incompatibility in how it
2009/10/14 kiorky kio...@cryptelium.net:
As i understood, NS.foo from setuptools can't be imported in NS.bar from
pkgutil
and vice versa.
Oh, in the same namespace? Yeah, that could break. Is that a problem?
Also, pkgutil doesn't know about setuptools, so possibly that breaks,
but its'
Lennart Regebro a écrit :
2009/10/14 kiorky kio...@cryptelium.net:
As i understood, NS.foo from setuptools can't be imported in NS.bar from
pkgutil
and vice versa.
Oh, in the same namespace? Yeah, that could break. Is that a problem?
Also, pkgutil doesn't know about setuptools, so
At 06:46 PM 10/14/2009 +0200, kiorky wrote:
As i understood, NS.foo from setuptools can't be imported in NS.bar
from pkgutil
and vice versa.
Not so. The true implementation of nsp's is in __path__, which is
provided by Python's import libraries, not setuptools or pkgutil.
At 04:55 PM 10/14/2009 +0200, Lennart Regebro wrote:
2009/10/14 kiorky kio...@cryptelium.net:
That's not what said the PEP (IOW what i had understood of)
Oh, you don't *use* it the same way, no, but I assumed that the
internal mechanisms would be similar. Maybe I was wrong.
You can use as
P.J. Eby a écrit :
At 06:46 PM 10/14/2009 +0200, kiorky wrote:
As i understood, NS.foo from setuptools can't be imported in NS.bar
from pkgutil
and vice versa.
Not so. The true implementation of nsp's is in __path__, which is
provided by Python's import libraries, not setuptools or
2009/10/14 P.J. Eby p...@telecommunity.com:
You can use as many namespace package mechanisms as you want,
simultaneously, as long as they're not all being used for the same namespace
package.
But the same namespace works. I couldn't believe kiorky's claim that
it wouldn't work, and I have now
On Wed, 14 Oct 2009 20:47:32 +0900, David Cournapeau
The good news is that there are existing tools in other environments
which do this in a pretty good way already, so we could steal their idea
and just reimplement the thing for python. This problem space has seen a
lot of new ideas since
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
2009/10/14 P.J. Eby p...@telecommunity.com:
You can use as many namespace package mechanisms as you want,
simultaneously, as long as they're not all being used for the same namespace
package.
But the same namespace works.
On Wed, Oct 14, 2009 at 5:59 PM, David Lyon david.l...@preisshare.net wrote:
ConfigParser is in every python version that I know of.
ConfigParser was first documented in Python 1.5.2, released 30 April 1999.
Some of us remember the releases that came before, but (thankfully)
we're outnumbered.
Hi Eric..
On Wed, 14 Oct 2009 08:46:26 -0400, Eric Smith e...@trueblade.com wrote:
The first one who mentioned the idea was Eric IIRC, then Matthias and
Tres worked on it.
Fine. They've been awfully quiet on distutils-sig lately :-)
Not so!
:-)
Sure. Well collect is a word ..
I'm
On Wed, 14 Oct 2009 11:21:40 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
My suggestion is that once you have a revised PEP that includes some
proof of concept
code with less overlapping with PEP 390 (they are different proposals
obviously),
you post it here for a round of feedback, then
David Lyon wrote:
We're not talking about too much more than a file copy and run script
api.
Saying that a packaging tool is about copying files is not very useful -
you could say that programming is just moving bytes around and you would
be right as well :)
I'm really not hung up on .ini
On Wed, 14 Oct 2009 18:52:57 -0700, Kevin Teague ke...@bud.ca wrote:
ConfigParser was first documented in Python 1.5.2, released 30 April
1999.
Some of us remember the releases that came before, but (thankfully)
we're outnumbered. :-)
1.5.1 was the first Python that I used, seems like
On Thu, 15 Oct 2009 10:59:48 +0900, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Saying that a packaging tool is about copying files is not very useful -
you could say that programming is just moving bytes around and you would
be right as well :)
Well it is about moving bytes around..
David Lyon wrote:
It's just too hard to do and adds another layer of complexity to
deal with.
Hence something like xml for a prototype and discussion - I did not
suggest to use xml for the end product package. I have as much love for
xml as the next python guy.
I don't like nesting in
On Wed, Oct 14, 2009 at 11:16 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
I don't think python 1.5 should be considered - I happen to contribute
to scons, which is a build tool in python, and supports all python
versions from 1.5.2: the 1.5 requirement is a real downside.
I hope
Fred Drake wrote:
On Wed, Oct 14, 2009 at 11:16 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
I don't think python 1.5 should be considered - I happen to contribute
to scons, which is a build tool in python, and supports all python
versions from 1.5.2: the 1.5 requirement is a
On Thu, 15 Oct 2009 12:16:48 +0900, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
I think nested conditions for configurations is a must-have. Once you
have more than 2-3 variables, doing it like PEP 390 is not really
manageable. Particularly for C extensions, having many configurations
David Lyon wrote:
[dependencies]
packages = pyopengl
[dependencies python=2.4]
packages = lxml = 2.5
[dependencies mac python=2.4]
packages = shinyxml
Translates roughly into the following python code:
dependencies = [pyopengl]
if sys.version = '2.4':
On Thu, 15 Oct 2009 13:39:32 +0900, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
I understand this, but when you a lot of conditioning, flattening the
conditions is not really readable. If you have say 10 variables instead
of 2 to condition on, the sections would be several lines.
I'm
2009/10/15 Tres Seaver tsea...@palladion.com:
Right, its just a race: whichever project gets its version of the
namespace package imported first wins, sets the __path__, and
everything works. No consolation prizes for the others, because they
*never get imported* (their __init__.py is never
2009/10/14 kiorky kio...@cryptelium.net:
In the context of migration, for example.
Take the plone collective namespace, all the modules won't be updated at the
same time, we will have a painful cohabitation time.
Well, making coordinated releases there is tricky, since there is
different
42 matches
Mail list logo
