On Tue, 5 May 2009 02:11:36 +0200, Tarek Ziadé
wrote:
> I am not sure to understand what you are explaining - when the python
> interpreter starts up, it doesn't load every installed package
> in memory. the loading happens when you do "import foo"
Correct. I didn't say it loads them all.
The
On Tue, May 5, 2009 at 2:00 AM, David Lyon wrote:
>
>
> On Tue, 5 May 2009 01:58:57 +0200, Tarek Ziadé
> wrote:
>
>> That is what entry points are providing : the ability to mark a code
>> locate anywhere in your installation
>> and to load it when needed in your execution context.
>
> ok - but d
On Tue, 5 May 2009 01:58:57 +0200, Tarek Ziadé
wrote:
> That is what entry points are providing : the ability to mark a code
> locate anywhere in your installation
> and to load it when needed in your execution context.
ok - but don't we already have this in site.py ? inside the
interpreter.
On Tue, May 5, 2009 at 1:47 AM, David Lyon wrote:
>
> Hi Tarek,
>
>
> On Tue, 5 May 2009 01:37:34 +0200, Tarek Ziadé
> wrote:
>
>> Furtermore, if we provide the ability to fill egg-info with third
>> party packages registered through
>> a plugin system, it make sense to prepare it at packaging ti
Hi Tarek,
On Tue, 5 May 2009 01:37:34 +0200, Tarek Ziadé
wrote:
> Furtermore, if we provide the ability to fill egg-info with third
> party packages registered through
> a plugin system, it make sense to prepare it at packaging time to
> avoid having to install this third party package
> on t
2009/5/3 P.J. Eby :
> At 12:03 PM 5/3/2009 +0200, Tarek Ziadé wrote:
>>
>> The name of each file will have to be normalized: all upper case with
>> no extensions.
>>
>> Any opinions ?
>
> I don't see any point to the normalization. However, being able to install
> arbitrary files in .egg-info is c
At 12:50 AM 5/5/2009 +0200, Tarek Ziadé wrote:
On Mon, May 4, 2009 at 7:51 PM, P.J. Eby wrote:
> At 06:01 PM 5/4/2009 +0200, Tarek Ziadé wrote:
>>
>> On Mon, May 4, 2009 at 5:48 PM, P.J. Eby wrote:
>> >> > I don't see any point to the normalization.
>> >>
>> >> To avoid different naming convent
On Mon, May 4, 2009 at 7:42 PM, Hanno Schlichting wrote:
> Tarek Ziadé wrote:
>> On Mon, May 4, 2009 at 6:12 PM, Floris Bruynooghe
>> wrote:
>>
>> Ok then, we will have to provide extra documentation to make people
>> understand that the '.egg-info' directory has absolutely nothing to do
>> with
On Mon, May 4, 2009 at 7:51 PM, P.J. Eby wrote:
> At 06:01 PM 5/4/2009 +0200, Tarek Ziadé wrote:
>>
>> On Mon, May 4, 2009 at 5:48 PM, P.J. Eby wrote:
>> >> > I don't see any point to the normalization.
>> >>
>> >> To avoid different naming conventions like:
>> >>
>> >> PKG-INFO, requires.txt, SO
On Mon, May 4, 2009 at 7:43 PM, Ian Bicking wrote:
> On Mon, May 4, 2009 at 11:31 AM, Tarek Ziadé wrote:
>>
>> Ok then, we will have to provide extra documentation to make people
>> understand that the '.egg-info' directory has absolutely nothing to do
>> with egg-the-format
>> but is rather a me
2009/5/4 P.J. Eby :
> At 06:31 PM 5/4/2009 +0200, Tarek Ziadé wrote:
>>
>> Ok then, we will have to provide extra documentation to make people
>> understand that the '.egg-info' directory has absolutely nothing to do
>> with egg-the-format
>> but is rather a metadata container.
>
> On the contrary;
At 06:01 PM 5/4/2009 +0200, Tarek Ziadé wrote:
On Mon, May 4, 2009 at 5:48 PM, P.J. Eby wrote:
>> > I don't see any point to the normalization.
>>
>> To avoid different naming conventions like:
>>
>> PKG-INFO, requires.txt, SOURCES.txt
>
> And the problem with that is...?
inconsistency, but rig
On Mon, May 4, 2009 at 11:31 AM, Tarek Ziadé wrote:
> Ok then, we will have to provide extra documentation to make people
> understand that the '.egg-info' directory has absolutely nothing to do
> with egg-the-format
> but is rather a metadata container.
>
> 'egg-info' was introduced with adding
Tarek Ziadé wrote:
> On Mon, May 4, 2009 at 6:12 PM, Floris Bruynooghe
> wrote:
>
> Ok then, we will have to provide extra documentation to make people
> understand that the '.egg-info' directory has absolutely nothing to do
> with egg-the-format
> but is rather a metadata container.
> So removi
At 06:31 PM 5/4/2009 +0200, Tarek Ziadé wrote:
Ok then, we will have to provide extra documentation to make people
understand that the '.egg-info' directory has absolutely nothing to do
with egg-the-format
but is rather a metadata container.
On the contrary; .egg-info *is* an egg format; see th
At 05:54 PM 5/4/2009 +0200, Tarek Ziadé wrote:
2009/5/4 P.J. Eby :
> At 05:23 PM 5/4/2009 +0200, Tarek Ziadé wrote:
>>
>> There's another point I was thinking about in PEP 376
>>
>> What about dropping the 'egg' part in 'PROJECT.egg-info' ? and replace it
>> with
>>
>> 'PROJECT.info'
>>
>> (and
On Mon, May 4, 2009 at 6:12 PM, Floris Bruynooghe
wrote:
>>
>> But what about the idea ?
>
>
> How can we be sure that we won't want to change it again in the
> future?
well I think it's now or never, since we are defining a standard here
for this directory.
> As for PROJECT.info, that still do
On Mon, May 04, 2009 at 05:54:59PM +0200, Tarek Ziadé wrote:
> 2009/5/4 P.J. Eby :
> > At 05:23 PM 5/4/2009 +0200, Tarek Ziadé wrote:
> >>
> >> There's another point I was thinking about in PEP 376
> >>
> >> What about dropping the 'egg' part in 'PROJECT.egg-info' ? and replace it
> >> with
> >>
>
On Mon, May 4, 2009 at 5:48 PM, P.J. Eby wrote:
>> > I don't see any point to the normalization.
>>
>> To avoid different naming conventions like:
>>
>> PKG-INFO, requires.txt, SOURCES.txt
>
> And the problem with that is...?
inconsistency, but right, it makes no sense if any file/dir can be adde
2009/5/4 P.J. Eby :
> At 05:23 PM 5/4/2009 +0200, Tarek Ziadé wrote:
>>
>> There's another point I was thinking about in PEP 376
>>
>> What about dropping the 'egg' part in 'PROJECT.egg-info' ? and replace it
>> with
>>
>> 'PROJECT.info'
>>
>> (and make the 2.7 version compatible with PROJECT.egg-
At 07:34 PM 5/3/2009 +0200, Tarek Ziadé wrote:
2009/5/3 P.J. Eby :
> At 12:03 PM 5/3/2009 +0200, Tarek Ziadé wrote:
>>
>> The name of each file will have to be normalized: all upper case with
>> no extensions.
>>
>> Any opinions ?
>
> I don't see any point to the normalization.
To avoid differen
At 05:23 PM 5/4/2009 +0200, Tarek Ziadé wrote:
There's another point I was thinking about in PEP 376
What about dropping the 'egg' part in 'PROJECT.egg-info' ? and
replace it with
'PROJECT.info'
(and make the 2.7 version compatible with PROJECT.egg-info )
I know it's a minor change,
Actu
There's another point I was thinking about in PEP 376
What about dropping the 'egg' part in 'PROJECT.egg-info' ? and replace it with
'PROJECT.info'
(and make the 2.7 version compatible with PROJECT.egg-info )
I know it's a minor change, but it seems that a lot of people are
confused with this,
2009/5/3 P.J. Eby :
> At 12:03 PM 5/3/2009 +0200, Tarek Ziadé wrote:
>>
>> The name of each file will have to be normalized: all upper case with
>> no extensions.
>>
>> Any opinions ?
>
> I don't see any point to the normalization.
To avoid different naming conventions like:
PKG-INFO, requires.tx
At 12:03 PM 5/3/2009 +0200, Tarek Ziadé wrote:
The name of each file will have to be normalized: all upper case with
no extensions.
Any opinions ?
I don't see any point to the normalization. However, being able to
install arbitrary files in .egg-info is currently supported by
setuptools, an
On Thu, Apr 30, 2009 at 9:34 AM, Tarek Ziadé wrote:
> Hi,
>
> I have reworked the PEP a little bit with people feedback.
>
> It needs more feedback :
> http://svn.python.org/projects/peps/trunk/pep-0376.txt
>
> - install/uninstall script
>
> I think the best solution is not to provide an install
David Lyon wrote:
>
> Let's just accept this as your final position..
>
> I'm led to believe that pip and enstaller both claim deinstallation of
> packages.
>
Yes - packages they have installed *themselves*. Nobody has ever claimed
that uninstallation is impossible - uninstallation of something
Tarek,
On Thu, 30 Apr 2009 17:29:40 +0200, Tarek Ziadé
wrote:
> And then, as we said earlier, it will be impossible to uninstall packages
> that were previously uninstalled with some other techniques since we
won't have
> the info required.
Let's just accept this as your final position..
I'm l
On Thu, 30 Apr 2009 14:01:31 -0400, "P.J. Eby"
wrote:
> A distribution found on PyPI such as "FooBar-2.79" is the 2.79
> release of the *project* "FooBar"... this tells you absolutely
> nothing about the names of packages or modules contained in that project.
Ok - but that's hardly my fault...
At 10:17 AM 4/30/2009 -0400, David Lyon wrote:
In summary... packages are just directories with an __init__.py
file in them. Sometimes they are zipped into eggs.
You are confusing "Python package" with "Python project". Projects
are zipped into eggs, and may contain zero or more
packages. P
On Thu, Apr 30, 2009 at 5:08 PM, David Lyon wrote:
> A typical user just wants to install package x,y and z from
> pypi. They want them to go "into python" and it is as simple
> as that. Those packages will probably end up in site-packages
> but as likely as not, the user won't care where they go
On Thu, 30 Apr 2009 16:48:32 +0200, Tarek Ziadé
wrote:
> No, you don't have the exaustive list of the files installed.
My testing indicates that pkg_resources works ok.
>> --code---
>>
>> import pkg_resources
>>
>> ws = pkg_resources.WorkingSet()
>>
>> for i in ws:
>> s = str(i)
>>
On Thu, Apr 30, 2009 at 4:34 PM, David Lyon wrote:
> Hi Tarek,
>
> On Thu, 30 Apr 2009 15:50:19 +0200, Tarek Ziadé
> wrote:
>>> But during package installation, this information will be written
>>> into a .PTH file somewhere along the python path...
>>
>> No, you just have a list of relative path
Hi Tarek,
On Thu, 30 Apr 2009 15:50:19 +0200, Tarek Ziadé
wrote:
>> But during package installation, this information will be written
>> into a .PTH file somewhere along the python path...
>
> No, you just have a list of relative paths to installed package there
> that's it.
It means the same t
Hi David,
On Thu, 30 Apr 2009 22:24:07 +0900, David Cournapeau
wrote:
> It is impossible to uninstall a package if you don't have a recording of
> what was installed.
Not true.
> Removing every directories is a bad idea, as it may
> remove files which were not installed by the package.
In
On Thu, Apr 30, 2009 at 3:32 PM, David Lyon wrote:
>
>
> On Thu, 30 Apr 2009 14:43:42 +0200, Tarek Ziadé
> wrote:
>>> That's true that they can be installed anywhere. But there always
>>> needs to be an entry in a .PTH file along the python path to
>>> specify where the files were installed to.
>
David Lyon wrote:
> If you have a deinstallation facility, then it must work for new
> packages as well as old. Otherwise, imho there's just no point.
>
It is impossible to uninstall a package if you don't have a recording of
what was installed. Removing every directories is a bad idea, as it m
On Thu, 30 Apr 2009 14:43:42 +0200, Tarek Ziadé
wrote:
>> That's true that they can be installed anywhere. But there always
>> needs to be an entry in a .PTH file along the python path to
>> specify where the files were installed to.
>
> You don't specify in this pth file that the package "foo"
On Thu, Apr 30, 2009 at 2:35 PM, David Lyon wrote:
>>
>> No because you can have files installed anywhere
>
> That's true that they can be installed anywhere. But there always
> needs to be an entry in a .PTH file along the python path to
> specify where the files were installed to.
You don't spe
On Thu, 30 Apr 2009 14:23:41 +0200, Tarek Ziadé
wrote:
> We are planning to propose a backport for previous versions
ok
>> Not neccessary - recursively delete the whole package directory or
>> .egg file.
>
> No because you can have files installed anywhere
That's true that they can be insta
On Thu, Apr 30, 2009 at 2:11 PM, David Lyon wrote:
> As far as I can see, it's just so much better to have a
> package uninstaller in a seperate gui tool. That can be
> installed over an existing installation.
We are planning to propose a backport for previous versions
> The big problem with us
On Thu, 30 Apr 2009 09:34:26 +0200, Tarek Ziadé
wrote:
> - install/uninstall script
>
> I think the best solution is not to provide an install script since
> third-party tool do it. Furthermore,
> there's already the simplest install script available today: you can
> run "python setup.py in
Hi,
I have reworked the PEP a little bit with people feedback.
It needs more feedback : http://svn.python.org/projects/peps/trunk/pep-0376.txt
- install/uninstall script
I think the best solution is not to provide an install script since
third-party tool do it. Furthermore,
there's already
43 matches
Mail list logo
