Even installing shortcuts doesn't need to munge the registry! But
regardless, you seem to be arguing that setuptools should morph into a
full-blown, general purpose installer for python build apps, capable of
doing all kinds of platform specific things which any app may desire - and
while I don't
Hi Mark,
Shortcuts don't, but file associations to those shortcuts do (at least
to the best of my understanding,) adding paths does, etc. I agree that
a library (extensions or no) doesn't need to do these things. But
anything targeted at an end-user on Windows has a reasonable chance of
On Wed, Apr 02, 2008 at 06:32:13PM -0500, Dave Peterson wrote:
Shortcuts don't, but file associations to those shortcuts do (at least to
the best of my understanding,) adding paths does, etc. I agree that a
library (extensions or no) doesn't need to do these things. But anything
Mark Hammond wrote:
(Note: I'm aware that people believe it to be necessary to munge the
Windows registry when installing Python packages; I just don't agree
with the practice, and don't think we should distort Python's process
to coddle it).
Whoever thinks it necessary is misguided.
On 25 Mar, 2008, at 20:11, Alexander Michael wrote:
You can see Floris Bruynooghe's response
earlier in the thread, but basically it is an even harder problem to
create packages for every major platform automatically than it is to
create a simple database of installed packages that plays well
On Thu, Mar 27, 2008 at 01:55:25PM +0100, Ronald Oussoren wrote:
On 25 Mar, 2008, at 20:11, Alexander Michael wrote:
You can see Floris Bruynooghe's response
earlier in the thread, but basically it is an even harder problem to
create packages for every major platform automatically than it is
On Mon, Mar 24, 2008 at 8:33 PM, Floris Bruynooghe
[EMAIL PROTECTED] wrote:
Something that this requirement should probably explicitly describe:
does this database only concern modules, i.e. installed in a directory
that's on sys.path? My understanding is that it does. However I'm
unsure
On Mon, Mar 24, 2008 at 10:35:01PM -0400, Phillip J. Eby wrote:
At 12:33 AM 3/25/2008 +, Floris Bruynooghe wrote:
1. If the current installation state satisfies the requirements of a
new package being considered for installation.
2. If it is safe for the administrator to upgrade or
At 09:16 AM 3/25/2008 +, Floris Bruynooghe wrote:
What would the motivation be for requiring to overwrite files created
by another tool? That seems rather dangerous to me.
The point is to NOT overwrite those files.
___
Distutils-SIG maillist -
Phillip J. Eby escreveu:
Of course, one possible solution is for both A and B to depend on a
virtual package that contains C, such that both A and B can install
it if it's not there, and list it in their dependencies.
No need. Is this is what you want?
At 05:45 PM 3/25/2008 +, Luis Bruno wrote:
Phillip J. Eby escreveu:
Of course, one possible solution is for both A and B to depend on a
virtual package that contains C, such that both A and B can install
it if it's not there, and list it in their dependencies.
No need. Is this is what
On Tue, Mar 25, 2008 at 1:45 PM, Luis Bruno [EMAIL PROTECTED] wrote:
Phillip J. Eby escreveu:
Of course, one possible solution is for both A and B to depend on a
virtual package that contains C, such that both A and B can install
it if it's not there, and list it in their dependencies.
At 03:11 PM 3/25/2008 -0400, Alexander Michael wrote:
I agree that if every python package provided a
MSI/DEB/RPM/MPKG/etc., then there wouldn't be a need to install python
packages without a system-level installer.
Even if they did, there would still be a need. System-level packages
aren't
On Sat, Mar 22, 2008 at 10:02 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
It seems to me that this discussion is being undermined by not
acknowledging the many use cases up front. There is no rationale
because there are too many tacit rationales.
I honestly, really, cannot imagine what
On Mon, Mar 24, 2008 at 04:57:44PM -0400, Alexander Michael wrote:
With that preamble, here's my attempt at an
explicit rationale for a database of installed packages (A.K.A. The
New PEP 262):
Nice effort, thanks.
Rationale
=
It is often necessary during the course of managing a
At 12:33 AM 3/25/2008 +, Floris Bruynooghe wrote:
On Mon, Mar 24, 2008 at 04:57:44PM -0400, Alexander Michael wrote:
With that preamble, here's my attempt at an
explicit rationale for a database of installed packages (A.K.A. The
New PEP 262):
Nice effort, thanks.
Rationale
On Fri, Mar 21, 2008 at 10:04:45PM -0400, Phillip J. Eby wrote:
At 02:31 AM 3/22/2008 +0100, Martin v. Löwis wrote:
However, I'm extremely skeptical that this can ever succeed
to the degree that whoever provides RPMs, .debs, or MSI
files will actually use such data, as they will find that
the
On Fri, Mar 21, 2008 at 9:31 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
The objections to the PEP remain the same as they were then,
though: In the requirements, it says we need, without saying
why we need. It then goes on saying we want (rephrased)
to duplicate APT and RPM, without
On Sat, Mar 22, 2008 at 12:33:49PM +0100, Martin v. Löwis wrote:
The data isn't for them to use to meet their use cases, it's for them to
*provide* so that Python tools don't stomp on, uninstall, or otherwise
interfere with files installed by the system. In other words, for
system
On 22/03/2008, Steve Holden [EMAIL PROTECTED] wrote:
Well, I've probably been killfiled into non-existence on this list by
now, but it seems to me that we are in danger of answering the wrong
problem yet again. But that's all I have to say on this topic, so you
can all heave a sigh a relief
It seems to me that this discussion is being undermined by not
acknowledging the many use cases up front. There is no rationale
because there are too many tacit rationales.
I honestly, really, cannot imagine what those are. Explicit is
better than implicit.
Nevertheless, the many
use cases
On 22/03/2008, Alexander Michael [EMAIL PROTECTED] wrote:
IOW, the PEP is lacking a rationale.
It seems to me that this discussion is being undermined by not
acknowledging the many use cases up front. There is no rationale
because there are too many tacit rationales.
Absolutely! It
Essentially, one would have to contribute patches to all the
distributions (we care about, at least), and then nag the respective
maintainers to include these patches.
Not true. You just need to make sure that setup.py install creates
that database. With the proposed format of the
On 22/03/2008, Martin v. Löwis [EMAIL PROTECTED] wrote:
How would you install multiple versions in the first place? Python
supports no such thing, at least not without setting PYTHONPATH,
or otherwise changing sys.path.
That's an unrelated feature of setuptools, providing a way to
install
At 11:00 AM 3/22/2008 +, Floris Bruynooghe wrote:
As long as systems (dpkg, rpm, ...) install the .egg-info files they
do communicate which modules/distributions are installed. The
installdb would just duplicate this information (according to the
current PEP).
.egg-info/PKG-INFO don't list
At 12:33 PM 3/22/2008 +0100, Martin v. Löwis wrote:
I probably should have brought this up, in fact, I think I
mentioned it in a previous thread, but I would like to see PEP 262
add a way to say this is a system-installed package, *don't
touch*. The idea again is not to do the job of the
On Sat, Mar 22, 2008 at 03:14:05PM +0100, Martin v. Löwis wrote:
Essentially, one would have to contribute patches to all the
distributions (we care about, at least), and then nag the respective
maintainers to include these patches.
Not true. You just need to make sure that setup.py
At 02:14 PM 3/22/2008 +, Paul Moore wrote:
For the system Python, I need:
- a single way to list what's installed (including version)
- a single way to uninstall items as needed
- a way (or more than one) to install 3rd party software *which ties
into the above*
Right, and the PEP effort is
For those without the read-only flag, the specification should
explicitly say what manipulation is allowed.
Since a distribution isn't really mutable, I would think that
uninstallation and reinstallation would be the only manipulation
available. (As distinct from inspection,
At 11:19 AM 3/22/2008 -0400, Phillip J. Eby wrote:
Not exactly. More like, package management tool X claims exclusive
rights to this package. Python tools would always defer this right
to the system packager, i.e. a system packager is not obliged to
respect a Python tool's claim to a file, but
I speak for Debian, so for Debian: yes. The setup.py would have to be
pretty bad for a packager to not use it. There is no reason to
re-write upstream's installation procedure as you would have to figure
out which files need to be installed where and this would create many
bugs.
The
On 22/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
This probably needs to be refined a little. Exclusive right is too
strong, and it goes against Paul Moore's desire for using a single
tool.
Huh? How's that? Don't forget that I'm on Windows, and on Windows
there is no system tool - just
At 04:29 PM 3/22/2008 +0100, Martin v. Löwis wrote:
For those without the read-only flag, the specification should
explicitly say what manipulation is allowed.
Since a distribution isn't really mutable, I would think that
uninstallation and reinstallation would be the only manipulation
In the case of Fedora rpms, the usual install uses setup.py.
Ok. Does it then also package all files that get installed into
the RPM file? If it produces multiple RPMs from a single source
package, how does it know which files go into what RPM?
Regards,
Martin
Huh? How's that? Don't forget that I'm on Windows, and on Windows
there is no system tool - just bdist_wininst, bdist_msi and
easy_install. The fact that bdist_wininst and bdist_msi link into the
system UI for listing and uninstallation doesn't make packages using
them system packages.
In
Oh, and application installation is (should be) completely different.
On Windows, applications should probably be bundled with their own
Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
standard is, so I'd have to defer to others.
This I disagree with. I think it's an
On Sat, Mar 22, 2008 at 04:42:36PM +0100, Martin v. Löwis wrote:
I speak for Debian, so for Debian: yes. The setup.py would have to be
pretty bad for a packager to not use it. There is no reason to
re-write upstream's installation procedure as you would have to figure
out which files need to
On 22/03/2008, Martin v. Löwis [EMAIL PROTECTED] wrote:
Oh, and application installation is (should be) completely different.
On Windows, applications should probably be bundled with their own
Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
standard is, so I'd have
Oh, and application installation is (should be) completely different.
On Windows, applications should probably be bundled with their own
Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
standard is, so I'd have to defer to others.
This I disagree with. I think
Phillip J. Eby wrote:
Second, there were no uninstall tools for it, so I'd have had to
write one myself. (Zed's easy_f'ing_uninstall to the contrary, it
ain't easy, and I have an aversion to deleting stuff on people's
systems without knowing what will break. There's a big difference
On Fri, Mar 21, 2008 at 2:47 PM, Phillip J. Eby [EMAIL PROTECTED]
wrote:
Second, there were no uninstall tools for it, so I'd have had to
write one myself. (Zed's easy_f'ing_uninstall to the contrary, it
ain't easy, and I have an aversion to deleting stuff on people's
systems without knowing
Joachim I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
Joachim files (and 'rmdir' directories, but not recursively) that it
Joachim created, and that have not been modified in the meantime (after
Joachim the installation).
That's not sufficient. Suppose file C
[EMAIL PROTECTED] writes:
Joachim I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
Joachim files (and 'rmdir' directories, but not recursively) that it
Joachim created, and that have not been modified in the meantime (after
Joachim the installation).
On Fri, Mar 21, 2008 at 11:21:49AM -0500, [EMAIL PROTECTED] wrote:
Joachim I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
Joachim files (and 'rmdir' directories, but not recursively) that it
Joachim created, and that have not been modified in the meantime (after
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
Joachim I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
Joachim files (and 'rmdir' directories, but not recursively) that it
Joachim created, and that have not been modified in the meantime (after
Joachim the
On 2008-03-21 14:47, Phillip J. Eby wrote:
So, to accomplish this, we (for some value of we) need to:
1. Hash out consensus around what changes or enhancements are needed
to PEP 262, to resolve the previously-listed open issues, those that
have come up since (namespace packages, dependency
On 21/03/2008, Phillip J. Eby [EMAIL PROTECTED] wrote:
Questions, comments... volunteers? :)
Sounds good. I won't volunteer as I have neither time nor expertise to
contribute much. But I'd like to see this happen, as it sounds like it
would address all my issues with setuptools (and just to
At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
I guess the only way to support all of these variants is
to use a filesystem based approach, e.g. by placing a file
with a special extension into some dir on sys.path.
The database logic could then scan sys.path for these
files, read the data and
On 2008-03-21 22:21, Phillip J. Eby wrote:
At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
I guess the only way to support all of these variants is
to use a filesystem based approach, e.g. by placing a file
with a special extension into some dir on sys.path.
The database logic could then
On Fri, Mar 21, 2008 at 03:02:25PM -0400, Phillip J. Eby wrote:
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
Joachim I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
Joachim files (and 'rmdir' directories, but not recursively) that it
Joachim created, and
At 10:17 PM 3/21/2008 +, Floris Bruynooghe wrote:
On Fri, Mar 21, 2008 at 03:02:25PM -0400, Phillip J. Eby wrote:
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
Joachim I think, the uninstall should _not_ 'rm -rf' but
only 'rm' the
Joachim files (and 'rmdir'
At 11:13 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
On 2008-03-21 22:21, Phillip J. Eby wrote:
At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
I guess the only way to support all of these variants is
to use a filesystem based approach, e.g. by placing a file
with a special extension into
On Fri, Mar 21, 2008 at 06:30:33PM -0400, Phillip J. Eby wrote:
At 10:17 PM 3/21/2008 +, Floris Bruynooghe wrote:
On Fri, Mar 21, 2008 at 03:02:25PM -0400, Phillip J. Eby wrote:
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
Joachim I think, the uninstall should _not_ 'rm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip J. Eby wrote:
At 10:17 PM 3/21/2008 +, Floris Bruynooghe wrote:
On Fri, Mar 21, 2008 at 03:02:25PM -0400, Phillip J. Eby wrote:
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
Joachim I think, the uninstall should _not_ 'rm
I'm making the assumption that the author(s) of PEP 262 had good
reason for including what they did, rather than assuming that we
should start the entire process over from scratch.
The objections to the PEP remain the same as they were then,
though: In the requirements, it says we need,
At 02:31 AM 3/22/2008 +0100, Martin v. Löwis wrote:
I'm making the assumption that the author(s) of PEP 262 had good
reason for including what they did, rather than assuming that we
should start the entire process over from scratch.
The objections to the PEP remain the same as they were then,
Phillip J. Eby wrote:
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
Joachim I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
Joachim files (and 'rmdir' directories, but not recursively) that it
Joachim created, and that have not been modified in the meantime
57 matches
Mail list logo
