Hi.
I would like to use support to namespace packages in setuptools, however
I have some doubts.
* will this feature be supported for future setup tools?
* is it efficient to use?
* any reason why one should not use it?
Thanks Manlio
___
Distutils-SI
Hi All,
I want to be able to do things such as:
from mortar import content
from mortar.sqlalchemy import storage
...but where mortar is distrubuted as one package and mortar.sqlalchemy
(and a whole lot more like it...) are distributed as seperate packages.
Is this possible?
cheers,
Chris
On Tue, Apr 20, 2010 at 12:07 AM, Manlio Perillo
wrote:
> Hi.
>
> I would like to use support to namespace packages in setuptools, however
> I have some doubts.
>
> * will this feature be supported for future setup tools?
> * is it efficient to use?
> * any reason why one should not use it?
FYI,
On Apr 21, 2010, at 05:37 PM, Baiju M wrote:
>On Tue, Apr 20, 2010 at 12:07 AM, Manlio Perillo
> wrote:
>> Hi.
>>
>> I would like to use support to namespace packages in setuptools, however
>> I have some doubts.
>>
>> * will this feature be supported for future setup tools?
>> * is it efficient t
On Wed, Apr 21, 2010 at 2:14 PM, Barry Warsaw wrote:
> On Apr 21, 2010, at 05:37 PM, Baiju M wrote:
>
>>On Tue, Apr 20, 2010 at 12:07 AM, Manlio Perillo
>> wrote:
>>> Hi.
>>>
>>> I would like to use support to namespace packages in setuptools, however
>>> I have some doubts.
>>>
>>> * will this fe
Manlio Perillo wrote:
> Hi.
>
> I would like to use support to namespace packages in setuptools, however
> I have some doubts.
>
> * will this feature be supported for future setup tools?
> * is it efficient to use?
>
I have heard that it is slow if you're operating on NFS, as it causes
lots mor
> Last time we've mentioned this pep on Python-dev, Martin said he would
> do its implementation.
>
> Therefore, I am not sure what's the state on his side,.. cc'ing him
Unfortunately, I haven't made any progress - I still *plan* to do it
before the 3.2 betas, though. Contributions are welcome, o
On Apr 21, 2010, at 08:45 PM, Martin v. Löwis wrote:
>> Last time we've mentioned this pep on Python-dev, Martin said he would
>> do its implementation.
>>
>> Therefore, I am not sure what's the state on his side,.. cc'ing him
>
>Unfortunately, I haven't made any progress - I still *plan* to do i
On Mon, Apr 19, 2010 at 20:37, Manlio Perillo wrote:
> Hi.
>
> I would like to use support to namespace packages in setuptools, however
> I have some doubts.
>
> * will this feature be supported for future setup tools?
All of Zope and Plone uses it all the time. Trust us, it won't
disappear ever.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro ha scritto:
> On Mon, Apr 19, 2010 at 20:37, Manlio Perillo
> wrote:
>> Hi.
>>
>> I would like to use support to namespace packages in setuptools, however
>> I have some doubts.
>>
>> * will this feature be supported for future setup
At 09:26 PM 4/21/2010 +0200, Manlio Perillo wrote:
But I do not want to use a feature that it is here for compatiblity
only, in a new project.
Python itself has supported namespace packages through a stdlib
utility since Python 2.3, and special import mechanism support has
been proposed for a
On Tue, Apr 20, 2010 at 3:37 AM, Manlio Perillo
wrote:
>
> * will this feature be supported for future setup tools?
> * is it efficient to use?
It is slower than "conventional" packages import. I still don't
understand the whole implementation well, but I think there is an
inherent added cost (i
At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
One problem with the setuptools implementation is
that several packages sharing the same namespace have files in common,
If that were actually true (it isn't), then it would be considered a
bug in setuptools.
When you build a package for s
On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby wrote:
> At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
>>
>> One problem with the setuptools implementation is
>> that several packages sharing the same namespace have files in common,
>
> If that were actually true (it isn't), then it would be cons
On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby wrote:
> At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
>>
>> One problem with the setuptools implementation is
>> that several packages sharing the same namespace have files in common,
>
> If that were actually true (it isn't), then it would be cons
At 04:36 PM 4/22/2010 +0900, David Cournapeau wrote:
On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby wrote:
> At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
>>
>> One problem with the setuptools implementation is
>> that several packages sharing the same namespace have files in common,
>
> If th
At 04:49 PM 4/22/2010 +0900, David Cournapeau wrote:
On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby wrote:
> At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
>>
>> One problem with the setuptools implementation is
>> that several packages sharing the same namespace have files in common,
>
> If th
On Fri, Apr 23, 2010 at 1:10 AM, P.J. Eby wrote:
> At 04:36 PM 4/22/2010 +0900, David Cournapeau wrote:
>>
>> On Thu, Apr 22, 2010 at 1:10 PM, P.J. Eby wrote:
>> > At 10:18 AM 4/22/2010 +0900, David Cournapeau wrote:
>> >>
>> >> One problem with the setuptools implementation is
>> >> that several
At 10:16 AM 4/23/2010 +0900, David Cournapeau wrote:
In my case, it is not even the issue of many eggs (I always install
things with --single-version-externally-managed and I forbid any code
to write into easy_install.pth). Importing pkg_resources alone
(python -c "import pkg_resources") takes h
On Fri, Apr 23, 2010 at 2:03 PM, P.J. Eby wrote:
> At 10:16 AM 4/23/2010 +0900, David Cournapeau wrote:
>>
>> In my case, it is not even the issue of many eggs (I always install
>> things with --single-version-externally-managed and I forbid any code
>> to write into easy_install.pth). Importing
On Fri, Apr 23, 2010 at 9:23 AM, David Cournapeau wrote:
> On Fri, Apr 23, 2010 at 2:03 PM, P.J. Eby wrote:
>> At 10:16 AM 4/23/2010 +0900, David Cournapeau wrote:
>>>
>>> In my case, it is not even the issue of many eggs (I always install
>>> things with --single-version-externally-managed and I
On Fri, Apr 23, 2010 at 4:51 PM, Tarek Ziadé wrote:
> On Fri, Apr 23, 2010 at 9:23 AM, David Cournapeau wrote:
>> On Fri, Apr 23, 2010 at 2:03 PM, P.J. Eby wrote:
>>> At 10:16 AM 4/23/2010 +0900, David Cournapeau wrote:
In my case, it is not even the issue of many eggs (I always instal
On Fri, Apr 23, 2010 at 10:30 AM, David Cournapeau wrote:
[..]
> This all sounds complicated. pkg_resources is already complicated
> enough (the other big reason why I don't use it in any of my
> packages). Without a clear specification of what pkg_resources or its
> successor is doing, caching an
On Fri, Apr 23, 2010 at 5:54 PM, Tarek Ziadé wrote:
> I am not sure what you are defining as "complicated". While pkg_resources
> is hard to read and it's a project on its own with many other
> features, the use case
> we are talking about here is dead simple:
>
> scan all sys.path entries to lo
On Fri, Apr 23, 2010 at 12:01 PM, David Cournapeau wrote:
> On Fri, Apr 23, 2010 at 5:54 PM, Tarek Ziadé wrote:
>
>> I am not sure what you are defining as "complicated". While pkg_resources
>> is hard to read and it's a project on its own with many other
>> features, the use case
>> we are talki
On Fri, Apr 23, 2010 at 7:16 PM, Tarek Ziadé wrote:
> But guessing is not the right thing to do for optimization, we need facts.
> So if you come back with some profiling information on your use case
> where it seems so slow
Here is what cProfile -s cum gives me for a script which only import
pk
On Fri, Apr 23, 2010 at 1:38 PM, David Cournapeau wrote:
> On Fri, Apr 23, 2010 at 7:16 PM, Tarek Ziadé wrote:
>
>> But guessing is not the right thing to do for optimization, we need facts.
>> So if you come back with some profiling information on your use case
>> where it seems so slow
>
> Here
At 04:23 PM 4/23/2010 +0900, David Cournapeau wrote:
Importing pkg_resources
causes many more syscalls than relatively big packages (~ 1000 for
python -c "", 3000 for importing one of numpy/wx/gtk, 6000 for
pkg_resources). Assuming those are unavoidable (and the current
namespace implementation
At 12:16 PM 4/23/2010 +0200, Tarek Ziadé wrote:
On Fri, Apr 23, 2010 at 12:01 PM, David Cournapeau wrote:
> On Fri, Apr 23, 2010 at 5:54 PM, Tarek Ziadé wrote:
>
>> I am not sure what you are defining as "complicated". While pkg_resources
>> is hard to read and it's a project on its own with ma
At 08:38 PM 4/23/2010 +0900, David Cournapeau wrote:
2750.0240.0000.1510.001 posixpath.py:351(realpath)
Ouch. So, over one third of the execution time is spent translating
symlinks? That seems... excessive.
___
Distutils-SI
On Sat, Apr 24, 2010 at 1:32 AM, P.J. Eby wrote:
>
> If you don't mind trying a simple test for me, would you patch your
> pkg_resources to comment out this loop:
>
> for pkg in self._get_metadata('namespace_packages.txt'):
> if pkg in sys.modules: declare_namespace(pkg)
On Sat, Apr 24, 2010 at 1:43 AM, P.J. Eby wrote:
> At 08:38 PM 4/23/2010 +0900, David Cournapeau wrote:
>>
>> 275 0.024 0.000 0.151 0.001 posixpath.py:351(realpath)
>
> Ouch. So, over one third of the execution time is spent translating
> symlinks? That seems... excessive.
Yes
On 2008-11-21 09:49, Chris Withers wrote:
> Hi All,
>
> I want to be able to do things such as:
>
> from mortar import content
> from mortar.sqlalchemy import storage
>
> ...but where mortar is distrubuted as one package and mortar.sqlalchemy
> (and a whole lot more like it...) are distributed a
At 02:45 PM 4/24/2010 +0900, David Cournapeau wrote:
Is there a
design document or something else decribing how the namespace
mechanism works for setuptools ? I would like to support namespace
package in my own packaging project, but it is not clear to me what
needs to be done on my side of thing
On Sun, Apr 25, 2010 at 03:34, P.J. Eby wrote:
> One thing that's not entirely clear at the moment in PEP 382, though, is
> that it doesn't really specify how the other sys.path entries are found and
> mapped -- presumably it's something like os.path.join(syspathentry,
> *pkgname.split('.')) -- bu
Where I work we're considering a change to moving a group of packages
to using namespaces. We want the namespace paths to reflect a
dependency hierarchy, and the current plan requires putting some
source code into actual module distributions at the level of some of
the namespace packages.
Example:
Am 14.12.2010 00:11, schrieb Brad Allen:
> Where I work we're considering a change to moving a group of packages
> to using namespaces. We want the namespace paths to reflect a
> dependency hierarchy, and the current plan requires putting some
> source code into actual module distributions at the l
On Mon, Dec 13, 2010 at 5:57 PM, "Martin v. Löwis" wrote:
> You can't put code into __init__.py of any of the namespace packages.
> Otherwise, having additional modules in any of these packages is fine.
Ok, that answers my question. Thanks!
___
Distuti
At 05:11 PM 12/13/2010 -0600, Brad Allen wrote:
Where I work we're considering a change to moving a group of packages
to using namespaces. We want the namespace paths to reflect a
dependency hierarchy,
Note that you don't *need* to use namespace paths to reflect
dependencies; the main purpose
On Mon, Dec 13, 2010 at 7:21 PM, P.J. Eby wrote:
> At 05:11 PM 12/13/2010 -0600, Brad Allen wrote:
>>
>> Where I work we're considering a change to moving a group of packages
>> to using namespaces. We want the namespace paths to reflect a
>> dependency hierarchy,
>
> Note that you don't *need* to
I am running into something very odd on an Ubuntu 11.10 system: it looks
like namespace packages are entirely broken there. Here is a pdb session
to demonstrate:
(Pdb) import repoze
(Pdb) repoze
'/home/wichert/lib/buildout/eggs/repoze.formapi-0.4.2-py2.7.egg/repoze/__init__.pyc'>
(Pdb) repoze.
I've been trying to build rpms of enthought system components. Some of
them use namespace packages. Those packages have the required __init__.py
files containing
"__import__('pkg_resources').declare_namespace(__name__)".
According to the Setuptools Guide, these __init__.py files are not to be
pa
See the posts from Felix Schwarz here a few days ago. It looks like
he ran into and
debugged the same issue. I haven't had a chance to wade into it. (I can't
say I'm looking forward to it.)
I'll try to get up to speed on this this weekend.
Jim
On Thu, Apr 12, 2012 at 6:16 AM, Wichert Akkerman
On Thu, Apr 12, 2012 at 12:16:22PM +0200, Wichert Akkerman wrote:
> I am running into something very odd on an Ubuntu 11.10 system: it
> looks like namespace packages are entirely broken there.
Interesting. As a data point: I use zc.buildout 1.5.2 on Ubuntu 11.10.
I haven't encountered any namesp
On Apr 12, 2012, at 05:51 PM, Marius Gedminas wrote:
>Interesting. As a data point: I use zc.buildout 1.5.2 on Ubuntu 11.10.
>I haven't encountered any namespace issues yet.
I haven't seen any issues with zc.buildout 1.5.2 on Ubuntu 12.04 either.
Cheers,
-Barry
signature.asc
Description: PGP
Hey,
Am 12.04.2012 15:38, schrieb Jim Fulton:
> See the posts from Felix Schwarz here a few days ago. It looks like
> he ran into and debugged the same issue. I haven't had a chance to wade into
> it. (I can't
> say I'm looking forward to it.)
I think my last two emails contain a detailed expl
Let me try to answer some questions that came up:
- the buildout I used to reproduce this is this one:
https://github.com/euphorie/Euphorie
- this was using buildout 1.5.2
On 2012-4-12 12:16, Wichert Akkerman wrote:
I am running into something very odd on an Ubuntu 11.10 system: it looks
li
At 04:42 PM 7/25/2007 -0400, Stanley A. Klein wrote:
>I've been trying to build rpms of enthought system components. Some of
>them use namespace packages. Those packages have the required __init__.py
>files containing
>"__import__('pkg_resources').declare_namespace(__name__)".
>
>According to the
At 12:34 PM 7/26/2007 -0400, Stanley A. Klein wrote:
>I disabled the __init__.py's on the namespace packages by renaming them. A
>sys.modules.keys() shows the namespace packages in the list. Then I
>interactively did the first three statements of the test_traits.py
>program:
>
>import unittest
>fr
At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
>I had the same error. Should I have put in an "import enthought" in all
>the others?
No, apparently the manual import doesn't help. Presumably the ones
you changed need something more like this:
import enthought; enthought.traits = sys.modu
On Thu, July 26, 2007 12:46 pm, Phillip J. Eby wrote:
> At 12:34 PM 7/26/2007 -0400, Stanley A. Klein wrote:
>>I disabled the __init__.py's on the namespace packages by renaming them.
>> A
>>sys.modules.keys() shows the namespace packages in the list. Then I
>>interactively did the first three st
On Wed, 2007-07-25 at 18:10 -0400, Phillip J. Eby wrote:
> At 04:42 PM 7/25/2007 -0400, Stanley A. Klein wrote:
> >I've been trying to build rpms of enthought system components. Some of
them use namespace packages. Those packages have the required
__init__.py
> >files containing
> >"__import__('p
It worked. Problem solved.
Thanks.
Stan Klein
On Thu, July 26, 2007 2:01 pm, Phillip J. Eby wrote:
> At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
>>I had the same error. Should I have put in an "import enthought" in all
>>the others?
>
> No, apparently the manual import doesn't help
> On Thu, July 26, 2007 2:01 pm, Phillip J. Eby wrote:
>> At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
>>> I had the same error. Should I have put in an "import enthought" in all
>>> the others?
>> No, apparently the manual import doesn't help. Presumably the ones
>> you changed need some
Ryan May wrote:
>> On Thu, July 26, 2007 2:01 pm, Phillip J. Eby wrote:
>>> At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
I had the same error. Should I have put in an "import enthought" in all
the others?
>>> No, apparently the manual import doesn't help. Presumably the ones
>>>
On Thu, August 9, 2007 4:02 pm, Ryan May wrote:
>> On Thu, July 26, 2007 2:01 pm, Phillip J. Eby wrote:
>>> At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
I had the same error. Should I have put in an "import enthought" in
all
the others?
>>> No, apparently the manual import
56 matches
Mail list logo
