Re: Debian Python policy & Upgrade Path (draft/proposal)

[Joel Rosdahl]

Ricardo Javier Cardenes <[EMAIL PROTECTED]> writes:

> I have fixed that, but not uploaded the package while the policy is
> on debate. I suppose this is the case of other maintainers too...

Yep.

Joel

-- 
Joel Rosdahl <[EMAIL PROTECTED]>   (PGP and GPG keys available)

Re: What should we do now?

[Gregor Hoffleit]

* Jérôme Marant <[EMAIL PROTECTED]> [011017 08:31]:
> Matthias Klose <[EMAIL PROTECTED]> writes:
> Quoted from Gregor:
> 
> "
> Python package maintainers should then change their packages to build
> python1.5-* and python2.1-* packages (python2.0 if needed), and make
> them depend on python1.5-base etc. That would remove the need for
> versioned dependencies.
> "
> 
> What is the exact policy?
> 
> Should all executable scripts begin with #!/usr/bin/env python1.5 (for 1.5)
> and #!/usr/bin/env python2.1 (for 2.1)?

For the sake of the consistency of the Debian system, I would say that
all scripts in Debian packages currently should not use /usr/bin/env,
but instead provide the direct path to the executable (i.e.
#!/usr/bin/python1.5 etc.).

Otherwise, you might break up all the carefully provided package
dependencies by installing a new Python version in /usr/local:

Say, you would install 2.1.2 in /usr/local. Now if /usr/local/bin would
precede /usr/bin in your path, then "#!/usr/bin/env python2.1" would
call up 2.1.2. Still, if a script would depend on something like
"python2.1-base, python2.1-imaging", it would break in this case, since
python2.1-imaging isn't available in this 2.1.2 installation.

Therefore, the most reliable way currently is to use
#!/usr/bin/pythonX.Y in all Debian-provided scripts.

Gregor

Re: What should we do now?

[Anthony Towns]

On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> Say, you would install 2.1.2 in /usr/local. 

How about we just say "Don't install other versions of python in
/usr/local" ?

Or even "If you install versions of python in /usr/local, things could
break.  We don't support this."

Or even "If you install a different subrelease of the version of python
you've got installed, you'll need to be careful to install all the
modules you use for that version of python too."

Optimise for the common case, and make it easy for people to stay within
the bounds of things we support. Don't obsess about making sure an admin
can never possibly break anything.

Without the admin going out of his way to break the system (by partially
installing a version of python in /usr/local, eg) are there any real
problems with executable scripts invoking "#!/usr/bin/env python",
and having "the appropriate" dependencies?

And again, this isn't an exercise in formal specification, it's more
important to get something that's effective, useful and easily implemented
right now than something that's provably correct assuming FHS and policy.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 "Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
   C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
  see http://azure.humbug.org.au/~aj/armadillos.txt



pgpmyvWGDIkxM.pgp
Description: PGP signature

Re: What should we do now?

[Neil Schemenauer]

Anthony Towns wrote:
> On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > Say, you would install 2.1.2 in /usr/local. 
> 
> How about we just say "Don't install other versions of python in
> /usr/local" ?

Please no.  Making this work properly is not hard.  Besides, if the
magic is "#!/usr/bin/env python" then we would have to say "don't
install other versions of python in your path".


  Neil

Get guaranteed traffic to your website today @ incredible prices

[mailing]

Are you looking for effective traffic to your website? Look no further...

**

For the first time on the Internet, Trafficdelivered.com offers you a 
centralised means or ordering high-quality traffic, with a members area where 
you can check how your traffic purchase is doing and be involved in the project.

Establish your web presence today with the most affordable marketing packages 
available on the Internet.

At an unbeliveable low cost we can deliver a flood of targeted prospects to 
your web page. 

Stop wasting time and energy on marketing techniques that never deliver the 
traffic. 
   
Your online business needs to survive. In less than 1 week we can have a steady 
flow of fresh prospects landing on your site... Guaranteed!

So why not start today? Go to http://www.trafficdelivered.com and start 
enjoying the benefits of Internet marketing.

Thank you for doing business with us. We look forward to providing you with the 
services you need to grow and maintain your unique online identity. We 
encourage you to visit our Web site regularly to learn about our expanding 
catalogue of traffic solutions/packages: http://www.trafficdelivered.com

Best regards,

TrafficDelivered Team

Re: What should we do now?

[Gregor Hoffleit]

* Neil Schemenauer <[EMAIL PROTECTED]> [011022 17:47]:
> Anthony Towns wrote:
> > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > Say, you would install 2.1.2 in /usr/local. 
> > 
> > How about we just say "Don't install other versions of python in
> > /usr/local" ?
> 
> Please no.  Making this work properly is not hard.  Besides, if the
> magic is "#!/usr/bin/env python" then we would have to say "don't
> install other versions of python in your path".

Exactly. IMHO this is a no-go, we should not restrict our users in that
way. Furthermore, would there be any reason at all for using
"#!/usr/bin/env" in Debian scripts ? I don't see any.

Btw, cf. the discussion thread on python-dev that I started by asking
that kind of question. The tendency was that in general every Python
application is guaranteed to work only on a specific Python version.
Mailman 2.0 only runs on Python 1.5.2. Mailman 2.1 runs on Python 2.0.
Zope 2.2 runs on Python 1.5.2. Zope 2.4 runs on Python 2.1. Every other
combination is just a lucky coincidency (cf. the python-dev archives at
http://mail.python.org/pipermail/python-dev/ for the full discussion).

I don't see any reason why we should actively work towards enabling a
user to override the intended version, with the potential damage of
breaking scripts.

If the maintainer of a script is really aware of a legitimate reason for
doing this, he is welcome to use /usr/bin/env.

Gregor

Re: What should we do now?

[dman]

On Mon, Oct 22, 2001 at 08:32:33AM -0700, Neil Schemenauer wrote:
| Anthony Towns wrote:
| > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
| > > Say, you would install 2.1.2 in /usr/local. 
| > 
| > How about we just say "Don't install other versions of python in
| > /usr/local" ?
| 
| Please no.  Making this work properly is not hard.  Besides, if the
| magic is "#!/usr/bin/env python" then we would have to say "don't
| install other versions of python in your path".

Actually it is simpler than that :

Don't install other versions of python in your path *with the same
name as the packaged version*.

If a script does 
#!/usr/bin/env python2.1

and I install 2.1.2 as 'py212' in /usr/local there will be no clash.


Whether or not it is a good idea, I will leave up to you to decide.

-D

Re: Proposed modification to the Python Policy

[Jérôme Marant]

Donovan Baarda <[EMAIL PROTECTED]> writes:

 
> I agree that it would be nice, but I think it can wait until there is better 
> Debian-wide support for clusters of workstations nfs-mounting /usr/share. As 
> it 

  Sorry, but this not a good reason for not implementing this.  Perl
  does it already and some Python aplications are still installed in
  /usr/share.

-- 
Jérôme Marant <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

http://marant.org

Debian Python policy & Upgrade Path (draft/proposal) [0.3.3]

[Matthias Klose]

A revised version:

- Included Donovan's proposals. Note that I left the paragraph
  about the "latest stable version", so that Gregor can't escape
  so easyly ;-)

- Recommend /usr/bin/env python over /usr/bin/python

- Add chapter of other python versions installed on the system
  (Anthony's and Neil's comments).

- Restructured chapter "Packaging Modules", new point, how the binary
  module could be packaged (like python-pqueue now).

- Updated the upgrade path to the state of the current packages in
  unstable (and for uploading the packages in
  http://ftp-master.debian.org/~doko/python/).


   Debian Python Policy
   

 Neil Schemenauer <[EMAIL PROTECTED]>

 Matthias Klose <[EMAIL PROTECTED]>

   version 0.3.3


---


Abstract


 This document describes the packaging of Python within the Debian
 GNU/Linux distribution and the policy requirements for packaged Python
 programs and modules.


Copyright Notice


 Copyright (C) 1999, 2001 Software in the Public Interest

 This manual is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the
 Free Software Foundation; either version 2 of the License, or (at your
 option) any later version.

 This is distributed in the hope that it will be useful, but WITHOUT
 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 for more details.

 A copy of the GNU General Public License is available as
 `/usr/share/common-licences/GPL' in the Debian GNU/Linux distribution
 or on the World Wide Web at The GNU Public Licence
 (http://www.gnu.org/copyleft/gpl.html).

 You can also obtain it by writing to the Free Software Foundation,
 Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.


---


Contents


 1.Python Packaging
 1.1.  Stable and Legacy Versions
 1.2.  Base Package
 1.3.  Module Path
 1.4.  Documentation

 2.Packaged Modules
 2.1.  Packaging Variants
 2.1.1. Support Only The Default Version
 2.1.2. Support a Particular Version(s)
 2.1.3. Support All/Most Versions (Including Default)
 2.2.  Module Package Names
 2.3.  Dependencies

 3.Python Programs
 3.1.  Version Independant Programs
 3.2.  Version Dependant Programs

 4.Programs Embedding Python
 4.1.  Building Embedded Programs
 4.2.  Embedded Python Dependencies

 5.Interaction with Locally Installed Python Versions

 A.Upgrade Procedure


---


1. Python Packaging
---


1.1. Stable and Legacy Versions
---

 There can be any number of Python packages available.  These must be
 named `python.-base' and include the file
 `/usr/bin/python.', where  and  represent the major and
 minor versions of the Python, respectively.

 At any given time, the package `python-base' should establish one of
 these packaged versions of Python as the default Debian Python.  The
 `python-base' package must depend on the default `python.-base',
 and provide a symlink `/usr/bin/python' to the default
 `/usr/bin/python.' binary.

 At any given time, the package `python-base' should represent the
 latest stable upstream version of Python, that Debian is able to get
 into the release.


1.2. Base Package
-

 In order to provide a minimal installation of Python for use by
 applications without requiring the whole of Python to be installed,
 the `python-base' package contains the binary and a basic set of
 modules.


1.3. Module Path


 Python searches three different locations for modules.  The module
 search path for Debian has been ordered to include these locations at
 the beginning of the path in the following order:

  /usr/local/lib/python./site-packages
  /usr/local/lib/site-python
  /usr/lib/python./site-packages


1.4. Documentation
--

 Python documentation is split out in separate packages
 `python.-doc'.  The package `python-doc' depends on the
 `python.-doc' (the documentation of the current stable upstream
 version of Python.

 TODO: Policy for documentation of third party packages.


---


2. Packaged Modules
---

Re: Debian Python policy & Upgrade Path (draft/proposal) [0.3.3]

[Neil Schemenauer]

Matthias Klose wrote:
> - Recommend /usr/bin/env python over /usr/bin/python

Again I must express my opposition to this idea.  Using /usr/bin/env
totally breaks dependencies.  There's no way that I'm going to let
Debian policy dictate what I can have in my path.

  Neil

Re: What should we do now?

[Anthony Towns]

On Mon, Oct 22, 2001 at 08:32:33AM -0700, Neil Schemenauer wrote:
> Anthony Towns wrote:
> > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > Say, you would install 2.1.2 in /usr/local. 
> > How about we just say "Don't install other versions of python in
> > /usr/local" ?
> Please no.  Making this work properly is not hard.  

Again, _why_ does this matter? Who does this? Is it even remotely common?
That people would even consider installing another version of python in
/usr/local surely just points to a problem with the Debian packaging, no?

The problems with using "#!/usr/bin/python1.5" is threefold: first, it
makes dependencies that much more complicated: *all* python scripts have
to depend on versioned modules in every way, ie "Depends: python1.5-base,
python1.5-glade, python1.5-gtk, python1.5-numeric", second it means *all*
python executables need to be modified at the source level for every
python upgrade, and finally it makes Debian veer away from upstream
standards for python scripts.

And all this for what, precisely?

If you install new versions of standard tools in /usr/local you have
to be careful. This applies to a hypothetical /usr/local/bin/dpkg, or
a /usr/local/bin/sed, or whatever. Going out of your way to make sure
it doesn't apply to a /usr/local/bin/python seems to this observer a
complete waste of time.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 "Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
   C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
  see http://azure.humbug.org.au/~aj/armadillos.txt