On Feb 24, 2009, at 12:48 PM, Andrew Straw wrote:
But that is already implemented via file/dir permissions.
That's what's beautiful about GNU stow. Look:
sudo mkdir /usr/local/stow/grozz
sudo chown `whoami` /usr/local/stow/grozz
python ./setup.py install --prefix=/usr/local/stow/grozz # LOOK
At 02:57 PM 2/24/2009 -0500, P.J. Eby wrote:
At 04:45 PM 2/24/2009 +0100, Ronald Oussoren wrote:
What about another interoperability hook for system packages: specify
a file that a (system) package manager can include into the egg-info
directory (or egg-file) to tell setuptools/pip that this egg
2009/2/24 P.J. Eby :
> At 09:39 AM 2/24/2009 +0100, Joachim König wrote:
>>
>> could the egg-info directory be put somewhere else (as a
>> configuration/command line option)?
>
> No, since it's used to identify the installed location of the code that goes
> with it, ala PEP 262. In other words,
At 06:21 PM 2/24/2009 +, Floris Bruynooghe wrote:
On Mon, Feb 23, 2009 at 09:53:17PM -0500, P.J. Eby wrote:
> So, the uninstallation code should simply not remove file(s) that are
> referenced by more than one manifest in the target directory -- a
> relatively simple, future-proof safeguard,
At 04:45 PM 2/24/2009 +0100, Ronald Oussoren wrote:
What about another interoperability hook for system packages: specify
a file that a (system) package manager can include into the egg-info
directory (or egg-file) to tell setuptools/pip that this egg is
managed by the system and hence shouldn't
Ronald Oussoren wrote:
>
> On 24 Feb, 2009, at 16:20, P.J. Eby wrote:
>>
>>> Indeed. Having an index file would make things a whole lot simpler.
>>
>> For *whom*? Certainly not for system packaging tools (rpm, deb, et al).
>>
>> A design goal should be to allow system packaging tools to install a
On Tue, Feb 24, 2009 at 04:39:24PM +0100, Ronald Oussoren wrote:
>
> On 24 Feb, 2009, at 13:33, Tarek Ziadé wrote:
>>
>>
>> 2009/2/24 Joachim König :
>>> An other option could be to put the egg-info dir into the package
>>> itself, e.g.
>>>
>>> zlib/
>>> __init__.py
>>> egg-info/
>>> PK
On Mon, Feb 23, 2009 at 09:53:17PM -0500, P.J. Eby wrote:
> At 01:50 AM 2/24/2009 +0100, Tarek Ziadé wrote:
>> PEP, because as far as I
>> can see, the namespace package boilerplate in setuptools is using
>> pkgutil.extend_path which
>> fixes __path__ variables on the fly. So I can't think of a cas
On 24 Feb, 2009, at 16:20, P.J. Eby wrote:
Indeed. Having an index file would make things a whole lot simpler.
For *whom*? Certainly not for system packaging tools (rpm, deb, et
al).
A design goal should be to allow system packaging tools to install a
static file footprint: i.e., inde
On 24 Feb, 2009, at 13:33, Tarek Ziadé wrote:
2009/2/24 Joachim König :
An other option could be to put the egg-info dir into the package
itself, e.g.
zlib/
__init__.py
egg-info/
PKG-INFO
MANIFEST
RECORD
...
This would require setuptools and pip to change the way t
P.J. Eby schrieb:
At 09:39 AM 2/24/2009 +0100, Joachim König wrote:
could the egg-info directory be put somewhere else (as a
configuration/command line option)?
No, since it's used to identify the installed location of the code
that goes with it, ala PEP 262. In other words, sys.path is its
At 01:33 PM 2/24/2009 +0100, Tarek Ziadé wrote:
Philip wrote:
> So, the uninstallation code should simply not remove file(s) that
are referenced by more than one manifest in the target directory --
a relatively simple, future-proof safeguard, that doesn't require
any specific knowledge of "nam
At 09:39 AM 2/24/2009 +0100, Joachim König wrote:
could the egg-info directory be put somewhere else (as a
configuration/command line option)?
No, since it's used to identify the installed location of the code
that goes with it, ala PEP 262. In other words, sys.path is its own
installation d
Philip wrote:
> When a distutils package does it. I'm not positive, but if 'pip' supports
> namespace packages without using .pth files, then it has to use a shared
> __init__ also.
>
> And in the long run, easy_install will do this too.
>
> So, the uninstallation code should simply not remove f
Tarek Ziadé wrote:
If you look at install_egg_info, it will add the Python version
http://svn.python.org/projects/python/trunk/Lib/distutils/command/install_egg_info.py
I am not sure either this should be kept. I don't see the rationale
either, since
sys.version is known at runtime, it seems su
15 matches
Mail list logo