tracking requested vs dependency installs in PEP 376 metadata

[Carl Meyer-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey all,

I propose adding a bit to the PEP 376 metadata that indicates whether a
package was installed by user request or as a dependency of another
package. This would allow (un)installer tools to intelligently remove
orphaned dependencies, if they so choose. There might be questions about
the details of such an uninstaller feature, but I'm not intending to
discuss that here. The metadata itself is simple enough to track, and
seems like it ought to be included for its future usefulness.

I propose adding a metadata file REQUIRED within the .egg-info
directory. The presence of this file indicates that the user
specifically required this distribution. The absence of the file
indicates that the distribution was installed as a dependency. The
contents of the file are not used.

For the API, I propose adding a "required" property to the Distribution
class, which would be True or False based on the presence or absence of
the REQUIRED file.

I've added a demo implementation to a fork of Tarek's pep376 repo on
bitbucket: http://bitbucket.org/carljm/pep376/changeset/0c8002e65cb7/

Thoughts?

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKzhXFFRcxmeyPUXIRAvPkAJ4+bBPrt0fvYi2u/LhpLo2KS9ImfACfX9oq
5gab4TRuuWWUknOO0SK2E6I=
=Dm+n
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[ianb]

On Thu, Oct 8, 2009 at 11:39 AM, Carl Meyer <carl@...> wrote:

I propose adding a metadata file REQUIRED within the .egg-info
directory. The presence of this file indicates that the user
specifically required this distribution. The absence of the file
indicates that the distribution was installed as a dependency. The
contents of the file are not used.

I can imagine adding a little information, basically a log of when and why and who installed the package.  For instance:

  agent: pip 0.5

  install-date: 2009-10-08T13:44:00UTC

  installed-for-user: False

  installed-for-package: OtherPackage==0.3 

Potentially a package could have multiple records, because multiple installers may in some sense touch a package (e.g., if you install YetAnotherPackage that requires the same library as OtherPackage).  You could use INI-style and maybe label each record with the date, like [2009-10-08T13:44:00UTC].

This information seems fairly easy to generate.  Updating it after installation would be nice, but also means already-installed packages can be written to, which is not as nice IMHO.  Being unable to write to this file should be a non-fatal error for an installer.

Either way, a package could become REQUIRED (or user-requested) at any time after it is installed.  E.g.:

  easy_install Markdown

  easy_install ElementTree # which is required by MarkDown

Now ElementTree should not be considered orphaned if MarkDown is removed.

--
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[menesis]

2009/10/8 Carl Meyer <carl@...>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hey all,
>
> I propose adding a bit to the PEP 376 metadata that indicates whether a
> package was installed by user request or as a dependency of another
> package. This would allow (un)installer tools to intelligently remove
> orphaned dependencies, if they so choose. There might be questions about
> the details of such an uninstaller feature, but I'm not intending to
> discuss that here. The metadata itself is simple enough to track, and
> seems like it ought to be included for its future usefulness.
>
> I propose adding a metadata file REQUIRED within the .egg-info
> directory. The presence of this file indicates that the user
> specifically required this distribution. The absence of the file
> indicates that the distribution was installed as a dependency. The
> contents of the file are not used.

Debian's Apt has this capability, see
https://wiki.ubuntu.com/PackageDependencyManagement . It keeps a
separate file to track the manually installed packages, and the flag
is named "Auto-Installed". REQUIRED is an ambiguous name -- is it
required by other packages, or wanted by user for any reason (and that
is the case)?

>
> For the API, I propose adding a "required" property to the Distribution
> class, which would be True or False based on the presence or absence of
> the REQUIRED file.
>
> I've added a demo implementation to a fork of Tarek's pep376 repo on
> bitbucket: http://bitbucket.org/carljm/pep376/changeset/0c8002e65cb7/
>
> Thoughts?
>
> Carl

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Toshio Kuratomi-2]

On Thu, Oct 08, 2009 at 12:39:33PM -0400, Carl Meyer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hey all,
>
> I propose adding a bit to the PEP 376 metadata that indicates whether a
> package was installed by user request or as a dependency of another
> package. This would allow (un)installer tools to intelligently remove
> orphaned dependencies, if they so choose. There might be questions about
> the details of such an uninstaller feature, but I'm not intending to
> discuss that here. The metadata itself is simple enough to track, and
> seems like it ought to be included for its future usefulness.
>
> I propose adding a metadata file REQUIRED within the .egg-info
> directory. The presence of this file indicates that the user
> specifically required this distribution. The absence of the file
> indicates that the distribution was installed as a dependency. The
> contents of the file are not used.
>
> For the API, I propose adding a "required" property to the Distribution
> class, which would be True or False based on the presence or absence of
> the REQUIRED file.
>
> I've added a demo implementation to a fork of Tarek's pep376 repo on
> bitbucket: http://bitbucket.org/carljm/pep376/changeset/0c8002e65cb7/
>
> Thoughts?
>

Note that Linux distributions have discussed this for ages and it's not

always as useful as a naive first thought would imply.  For instance, there
are often many scripts written by a system administrator (or a user) that
might need to have a module installed.  This is not to say that it's a bad
idea to record this information -- there could be some installers for
specific use cases might find it useful or that it could be useful with
confirmation by the user.

Also note that a package manager should be able to tell required status from
what is currently installed.  So it might make more semantic sense to record
what was requested by the user to be installed instead of what was required
by a package.  (When something is both required by a package and requested
by a user, the user request is what takes precedence.)

-Toshio


_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Carl Meyer-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Ian Bicking wrote:

> I can imagine adding a little information, basically a log of when and
> why and who installed the package.  For instance:
>
>   agent: pip 0.5
>   install-date: 2009-10-08T13:44:00UTC
>   installed-for-user: False
>   installed-for-package: OtherPackage==0.3
>
> Potentially a package could have multiple records, because multiple
> installers may in some sense touch a package (e.g., if you install
> YetAnotherPackage that requires the same library as OtherPackage).  You
> could use INI-style and maybe label each record with the date, like
> [2009-10-08T13:44:00UTC].

Sure; I considered this possibility too, but wanted to keep the initial
proposal to "the simplest thing that could possibly work." I have no
problem with a log-style approach that includes more information, and if
it makes sense to others I can work on the implementation.

> This information seems fairly easy to generate.  Updating it after
> installation would be nice, but also means already-installed packages
> can be written to, which is not as nice IMHO.  Being unable to write to
> this file should be a non-fatal error for an installer.

Agreed. In my simple proposal, the only time an already-installed
package would need to be touched again is if you're
explicitly-installing an already-installed dependency (as in your
example below). In that case the REQUIRED file would be added, but in
that case touching the installation should be both possible and
uncontroversial, since you're specifically asking "again" to install it.

> Either way, a package could become REQUIRED (or user-requested) at any
> time after it is installed.  E.g.:
>
>   easy_install Markdown
>   easy_install ElementTree # which is required by MarkDown
>
> Now ElementTree should not be considered orphaned if MarkDown is removed.

Exactly.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD4DBQFKzj57FRcxmeyPUXIRAvtfAJ4wu1d+30FF1nmSu23qKGshLphPYACXfwqs
04ISfNfoulbSf0HGDZ3f6g==
=vQ0O
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Carl Meyer-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gediminas Paulauskas wrote:
> Debian's Apt has this capability, see
> https://wiki.ubuntu.com/PackageDependencyManagement . It keeps a
> separate file to track the manually installed packages, and the flag
> is named "Auto-Installed". REQUIRED is an ambiguous name -- is it
> required by other packages, or wanted by user for any reason (and that
> is the case)?

I agree that the name is not ideal. Perhaps naming the file
AUTO_INSTALLED, and flipping the semantics (so the presence of the file
allows it to be considered orphaned) would be better.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKzj7nFRcxmeyPUXIRAg+UAJkB51TXE/gKEOcsIhC7ID6/EhZbZACfcNS2
ZT7zcYCyy6VLy2qyxr6o+Ys=
=q2mH
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Carl Meyer-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Toshio Kuratomi wrote:
> Note that Linux distributions have discussed this for ages and it's not
> always as useful as a naive first thought would imply.  For instance, there
> are often many scripts written by a system administrator (or a user) that
> might need to have a module installed.  This is not to say that it's a bad
> idea to record this information -- there could be some installers for
> specific use cases might find it useful or that it could be useful with
> confirmation by the user.

Sure, I'm aware of these issues, and didn't want to get too deep into
implementation choices of (un)install tools. But it seems clear that
under some circumstances it could be useful to have a record of which
packages were installed "intentionally."

> Also note that a package manager should be able to tell required status from
> what is currently installed.  So it might make more semantic sense to record
> what was requested by the user to be installed instead of what was required
> by a package.  (When something is both required by a package and requested
> by a user, the user request is what takes precedence.)

Clearly my terminology choice was poor. REQUIRED in my proposal meant
"requested by name by a user" (which has to be recorded at install
time), not "required as a dependency by other installed packages"
(which, as you say, can be calculated at runtime). Would REQUESTED, or
AUTO_INSTALLED (with the sense flipped) be better options?

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKzkB4FRcxmeyPUXIRArxxAJ9B2YcLng0H0fSbTtLztKc5ILmvWACfcF0y
qztiKsrXS9usj14Iz37OE1g=
=AlFA
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Toshio Kuratomi-2]

On Thu, Oct 08, 2009 at 03:41:44PM -0400, Carl Meyer wrote:

> > Also note that a package manager should be able to tell required status from
> > what is currently installed.  So it might make more semantic sense to record
> > what was requested by the user to be installed instead of what was required
> > by a package.  (When something is both required by a package and requested
> > by a user, the user request is what takes precedence.)
>
> Clearly my terminology choice was poor. REQUIRED in my proposal meant
> "requested by name by a user" (which has to be recorded at install
> time), not "required as a dependency by other installed packages"
> (which, as you say, can be calculated at runtime). Would REQUESTED, or
> AUTO_INSTALLED (with the sense flipped) be better options?
>

I would say REQUESTED due to my arguments for not recording

installed-as-package-dependency.

-Toshio


_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

Ian Bicking wrote:

> I can imagine adding a little information, basically a log of when and
> why and who installed the package.  For instance:
>
>   agent: pip 0.5
>   install-date: 2009-10-08T13:44:00UTC
>   installed-for-user: False
>   installed-for-package: OtherPackage==0.3
>
> Potentially a package could have multiple records, because multiple
> installers may in some sense touch a package (e.g., if you install
> YetAnotherPackage that requires the same library as OtherPackage).  You
> could use INI-style and maybe label each record with the date, like
> [2009-10-08T13:44:00UTC].

Carl:
> Sure; I considered this possibility too, but wanted to keep the initial
> proposal to "the simplest thing that could possibly work." I have no
> problem with a log-style approach that includes more information, and if
> it makes sense to others I can work on the implementation.

I'd go for the simplest approach at first.

On Thu, Oct 8, 2009 at 9:52 PM, Toshio Kuratomi <a.badger@...> wrote:
> I would say REQUESTED due to my arguments for not recording
> installed-as-package-dependency.

+1

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[menesis]

2009/10/8 Carl Meyer <carl@...>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gediminas Paulauskas wrote:
>> Debian's Apt has this capability, see
>> https://wiki.ubuntu.com/PackageDependencyManagement . It keeps a
>> separate file to track the manually installed packages, and the flag
>> is named "Auto-Installed". REQUIRED is an ambiguous name -- is it
>> required by other packages, or wanted by user for any reason (and that
>> is the case)?
>
> I agree that the name is not ideal. Perhaps naming the file
> AUTO_INSTALLED, and flipping the semantics (so the presence of the file
> allows it to be considered orphaned) would be better.

For backwards compatibility already installed packages have to be
treated as manually installed, because it is not known why they were
installed. So the presence of a new file or flag has to signify that
it was AUTO_INSTALLED, i.e. the other way around than originally
suggested.

Gediminas
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Chris Withers]

Ian Bicking wrote:
> I can imagine adding a little information, basically a log of when and
> why and who installed the package.  For instance:
>
>   agent: pip 0.5
>   install-date: 2009-10-08T13:44:00UTC
>   installed-for-user: False
>   installed-for-package: OtherPackage==0.3

I think this is a great idea. Recording more information rather than
less and making sure it's kept up to date is a good idea here.
Otherwise, when tools come along later down the line that want to make
use of this information, they'll have to hack something themselves, and
that's what got setuptools into the mess it currently is in the first place!

Chris


_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Carl Meyer-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gediminas Paulauskas wrote:
> For backwards compatibility already installed packages have to be
> treated as manually installed, because it is not known why they were
> installed. So the presence of a new file or flag has to signify that
> it was AUTO_INSTALLED, i.e. the other way around than originally
> suggested.

I don't believe this is actually an issue. The PEP 376 installation
format is markedly different from any existing installation format, so
any tool dealing with installed packages will already have to know
whether it's dealing with a PEP 376 install or a legacy install. Only
PEP 376 installs could be considered orphaned.

I don't have a problem with AUTO_INSTALLED, but more people seem to have
favored REQUESTED thus far.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKzzcYFRcxmeyPUXIRApWuAKCHDSfd0rKwNWeZkQPy71wyz/fJFwCdFUw7
XPWhAA4c0r+SFMzuFmz2rKo=
=tAZN
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Carl Meyer-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Toshio Kuratomi wrote:
> I would say REQUESTED due to my arguments for not recording
> installed-as-package-dependency.

REQUESTED is fine, but I don't understand how the arguments apply, given
that I'm not proposing to record information like _which_ package it was
a dependency of. The same single bit (literally) of information is
tracked either way, it's just a question of whether the presence or
absence of a file signifies that bit.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKzzeSFRcxmeyPUXIRAo0iAJ9QdQzxVUhTBO+rEGgCKmFg9zH7EwCcCfPc
lWgoZVc+Z+H2OcIw1V/wNLI=
=k12Y
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Carl Meyer-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Withers wrote:

> Ian Bicking wrote:
>> I can imagine adding a little information, basically a log of when and
>> why and who installed the package.  For instance:
>>
>>   agent: pip 0.5
>>   install-date: 2009-10-08T13:44:00UTC
>>   installed-for-user: False
>>   installed-for-package: OtherPackage==0.3
>
> I think this is a great idea. Recording more information rather than
> less and making sure it's kept up to date is a good idea here.
> Otherwise, when tools come along later down the line that want to make
> use of this information, they'll have to hack something themselves, and
> that's what got setuptools into the mess it currently is in the first
> place!

The downside here is that it introduces one more wrinkle for installers
to worry about handling correctly. There are strong use cases for the
single bit "requested vs auto-installed"; nobody's yet presented use
cases for the additional log info. The only thing that comes to my mind
is UI niceties: being able to tell the user when, why, and by what agent
a package was installed. I'm not aware of existing package managers that
go that far; doesn't mean it's a bad idea.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKzzjZ1j/fhc23WEARAvw+AKDInwCU+Zzr6NIxlSUeOX+KWB+O6wCg2BWU
BVwtV1ndSSmJJcJmxKGu9kU=
=XQ57
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Alex Grönholm-3]

Carl Meyer kirjoitti:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Toshio Kuratomi wrote:
>  
>> I would say REQUESTED due to my arguments for not recording
>> installed-as-package-dependency.
>>    
>
> REQUESTED is fine, but I don't understand how the arguments apply, given
> that I'm not proposing to record information like _which_ package it was
> a dependency of. The same single bit (literally) of information is
> tracked either way, it's just a question of whether the presence or
> absence of a file signifies that bit.
>  

And what if the package is a dependency for multiple packages?
Let's say we have packages A and B which are installed separately, in
that order, and both depend on C.
C gets installed with information that it was required by A. Now if A is
uninstalled, won't C also get uninstalled?

> Carl
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFKzzeSFRcxmeyPUXIRAo0iAJ9QdQzxVUhTBO+rEGgCKmFg9zH7EwCcCfPc
> lWgoZVc+Z+H2OcIw1V/wNLI=
> =k12Y
> -----END PGP SIGNATURE-----
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@...
> http://mail.python.org/mailman/listinfo/distutils-sig
>  

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Carl Meyer-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Alex wrote:

> REQUESTED is fine, but I don't understand how the arguments apply, given
> > that I'm not proposing to record information like _which_ package it was
> > a dependency of. The same single bit (literally) of information is
> > tracked either way, it's just a question of whether the presence or
> > absence of a file signifies that bit.
> >
> And what if the package is a dependency for multiple packages?
> Let's say we have packages A and B which are installed separately, in
> that order, and both depend on C.
> C gets installed with information that it was required by A. Now if A is
> uninstalled, won't C also get uninstalled?

No. We are NOT talking about recording the full dependency graph in
package metadata. It is, as has always been the case, up to an uninstall
tool to calculate the depgraph based on actual installed packages at
runtime. A package is "orphaned" iff it was not REQUESTED by the user
AND it is no longer depended on by other installed packages.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKzz531j/fhc23WEARAlPfAJ93YHsbpzp5kF7hR0f98aSMOae6MwCgrP52
RZs5FU3h0U0eUBN2vgqm2HA=
=jyi8
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[exarkun]

On 01:45 pm, carl@... wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>Alex wrote:
>>REQUESTED is fine, but I don't understand how the arguments apply,
>>given
>> > that I'm not proposing to record information like _which_ package it
>>was
>> > a dependency of. The same single bit (literally) of information is
>> > tracked either way, it's just a question of whether the presence or
>> > absence of a file signifies that bit.
>> >
>>And what if the package is a dependency for multiple packages?
>>Let's say we have packages A and B which are installed separately, in
>>that order, and both depend on C.
>>C gets installed with information that it was required by A. Now if A
>>is
>>uninstalled, won't C also get uninstalled?
>
>No. We are NOT talking about recording the full dependency graph in
>package metadata. It is, as has always been the case, up to an
>uninstall
>tool to calculate the depgraph based on actual installed packages at
>runtime. A package is "orphaned" iff it was not REQUESTED by the user
>AND it is no longer depended on by other installed packages.

By doing this, I think you're dooming any Python package uninstaller to
be unpleasantly slow.

Jean-Paul
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Carl Meyer-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



exarkun@... wrote:
> By doing this, I think you're dooming any Python package uninstaller to
> be unpleasantly slow.

The process of searching for orphaned packages may be relatively slow on
a system with many installed packages. I'm not sure this is a serious
problem. I don't assume that an uninstaller implementation would (or
should) automatically search for orphaned packages any time it takes any
action. I also don't assume that tools could not maintain their own
persistent caches of depgraph information to speed up certain
operations. I do think there is some sense in leaving these choices to
tool creators and keeping the metadata standard simple.

If you'd like to propose that package installers should update the
metadata of every dependency of an installed or removed package, so that
each package always contains a full and reliable record of what other
packages on the system depend on it, that would be interesting. But it
is not this proposal.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKz0T51j/fhc23WEARAvyHAKCncp3D1BMBzDXKAmV8SIQqAdqkAgCgvIYT
3Du1wO9sftj5nAKHEgpnf3I=
=gjq3
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Chris Withers]

Carl Meyer wrote:
> The downside here is that it introduces one more wrinkle for installers
> to worry about handling correctly.

How so?

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Carl Meyer-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Chris Withers wrote:
> Carl Meyer wrote:
>> The downside here is that it introduces one more wrinkle for installers
>> to worry about handling correctly.
>
> How so?

Write some more metadata, figure out whether to write it to
already-installed packages, etc. Not saying it's a hard problem, just
one more thing to do. I already said I'm not opposed to it in theory,
but (as I also said) haven't seen strong use cases for it. Mostly I
don't want the (slightly) better to be the enemy of the good; the
REQUESTED bit is the critical part we don't have now.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKz0pl1j/fhc23WEARAoEXAKDUsgEMOILvr3dvFMdc6PiN6MNqGgCbBvyb
ttaA1Z3zbj7nIsC8FqOFf6c=
=4ynG
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig