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 some dir on sys.path.
The
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
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 install creates
that database. With the
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
Phillip == Phillip J Eby [EMAIL PROTECTED] writes:
Phillip At 07:00 AM 3/19/2008 +0100, Terry Jones wrote:
I guess I'm missing something here?
Phillip Whoops, my bad. 'get_finalized_command' is a distutils *command
Phillip object* method, not a distribution method. I usually work with
Phillip
On Saturday 22 March 2008, Martin v. Löwis wrote:
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
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 Fri, Mar 21, 2008 at 3:57 PM, Chris Withers [EMAIL PROTECTED] wrote:
Apologies if these questions have been answered elsewhere, if they have,
please point me at the answers. I've been trying to follow the discussion
but the shear volume has overwhelmed me...
1. Is there a canonical way
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
28 matches
Mail list logo
