On Mar 24, 2008, at 3:26 PM, Tres Seaver wrote:
> Sharing the system python is hugely problematic on a unix box which
> actually *uses* python for its own tools: the application is not
> "safe"
> from additions / updates / removeals of the packages in
> /usr/lib/python2.x/site-packages done to
On Sat, Mar 22, 2008 at 02:31:34AM +0100, "Martin v. L?wis" wrote:
> > Tools which will need this data, in order to do their work. Hence,
> > the reason for standardizing the data, instead of the tool(s).
>
> If there was a chance that the infrastructure being developed
> actually helps these to
Phillip J. Eby wrote:
> ... if tools exist and are distributed for such a [PEP 262] "database",
> and *everybody* agrees to use it as an officially-blessed standard,
> then it should be possible for setuptools to co-exist with that
> framework, and we're all happy campers.
I like this idea and
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 i
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 wh
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",
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 file
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 "
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
> > sy
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 tha
> 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
__
> 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.
>
> Th
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
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 lis
"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
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
"ins
>> 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
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 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 ca
On 21/03/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> You're heading off in the wrong direction: we should not be trying
> to rewrite RPM or InnoSetup in Python.
>
> Anything more complicated should be left to tools which are
> specifically written to manage complex software setups.
>
> I h
20 matches
Mail list logo
