Re: The Python Registrar
On Sun, Feb 24, 2002 at 10:35:47AM +1100, Donovan Baarda wrote:
> On Sat, Feb 23, 2002 at 03:31:26PM -0500, Jim Penny wrote:
> >
> > > The python-central approach attempts to provide a single package that
> > > supports multiple versions of python.
> > >
> > > > Education of end-users and even packagers is important. It cannot be
> > > > overemphasized to all involved that this works only for pure python
> > > > modules (and maybe pure python programs). It does not, can not, and
> > > > probably will never work for python "C-extension" modules.
> > >
> > > Yeah, but the policy already acknoleges and supports that, and quite well.
> > >
> > > > This does worry me a bit. It requires end-users to know the difference.
> > > > How do we educate them?
> > >
> > > End users don't have to know the difference, provided packagers get it
> > > right. The dependancies will handle it all for them.
> > >
> >
> > Ah, but they do. Some packages install automatically, even in places
> > that they are not necessarily wanted ("pure python modules"). Some
> > never install automatically, even in places where they are wanted
> > ("C-extension modules"). [Although C-extension modules should be
> > automatically upgraded when the default python changes.] This is really
> > quite different behavior and requires whoever has root to know and make
> > the distinction.
>
> The packages, provided they are built right, will be pretty self
> explanitory. Installing "python-foo" will install python-foo for the default
> python, "python2.1-foo" will install python-foo for python2.1. You are right
> that if "python-foo" happens to be a python-central package, it will also
> install for any other installed and supported python versions, but I can't
> see that this is a problem. If it is a python-central package, there will be
> no corresponding "python2.1-foo" package.
This is only NOT a problem if you
1) guarantee that the amount of total space of python-central
registerable packages is negligible.
or 1a) have a way of allowing the root users to easily override
installation of undesired packages.
and 2) have a way for the packager to express exactly which pythons the
package is known to run under.
Now, some of these proposals have either not expressed, or allowed to
be open-ended 2). If you have a system that permits only a finite list
of pythons to be expressed, I have no real objection to part 2).
If you are arguing that total space is negligible on end-user machines,
but not negligible on Debian repositories, well, this is where you begin
to lose me. See "What Evidence", below.
>
> For C module's, admins wanting to add python-foo for version 2.1 will have
> to explicitly install "python2.1-foo". Note that if python2.1 happens to be
> the default python, "python-foo" will be an empty package that depends on
> "python2.1-foo".
>
> Of course, the current policy does not require that packagers support all
> versions of python, so there is no garrentees that "python2.1-foo" will
> exist, or that a python-central "python-foo" will support python2.1. A quick
> glance at the dependancies will tell you what python-foo works for.
BTW: I agree with this, and there in fact sould be no such policy. If a
package works only under 2.2, it may be very difficult to backport to
2.1 or 1.5.2. I do believe, however, that policy should be amended to
encourage packagers to support as wide a range of pythons as possible,
and to accurately record/report for which pythons the package is
available and has been tested.
>
> > Restated, if you think of these packages only as "python modules", it may
> > violate the principle of least surprise that sometimes you install a
> > package and forget about it, and other times you install a package and
> > have to reinstall each time an additional python is introduced to the
> > system you administer.
>
> You don't have to re-install every time an additional python is introduced.
> If python-central becomes accepted as part of the policy, installing a new
> python will compile all python-central modules for the new python in the
> pythonX.Y's postinst.
>
Either you are misreading, or you are ignoring the import of this
argument.
Suppose you are not a python specialist, but just a root administrator
who has been asked to install an extra python on a multi-user machine.
Which is the easier rule for you to remember and follow?
A) Current python policy, with no exception made for pure python modules:
"You must know what the 'current python' is. (which you can find out by
apt-cache show python.) You can determine the set of packages installed
for the current python using dpkg -l | fgrep python-.
For any other python, you must install pythonX.Y-foo, if your
users need it. After investigation, if no pythonX-Y.foo is available,
you should file a bug report."
or
B) Current python policy, with python-central, or cognate:
"You must know what set of python packages you have installed on your
system. You can determine this by dpkg -l | fgrep python-. For those
packages which contain "pure python modules", you need do nothing more.
You can determine that a package is a pure python modules because it
depends on python-central, which you can determine by looking at
apt-cache show package_name. If there are any remaining packages,
you need to know what the current python is. You can determine this
by using apt-cache show python. All of these other packages must be
installed by apt-get install pythonX.Y-foo. After investigation,
if pythonX.Y-foo is not available, or if "pure python module" python-foo
is available, but is not listed as compatible with pythonX.Y, you
should file a bug report. The compatibility of pure python module
python-foo with pythonX.Y may be found by looking at the Depends line
found as a result of apt-cache show python-foo".
What kind of evidence should be considered in determining if
python-central should be made part of policy?
How many pure python modules are there? What is their total size
in .deb form? What is their size on the client? How much do the .pyo
and .pyc files add to this? How much would it add to the Debian
packages file to have them packaged analogously to C-extension modules?
If you make the engineering argument that the amount of space saved
on Debian mirrors is substantial, (or maybe that amount of space saved in
the Packages file is substantial); and that the amount of space wasted
on user machines is not substantial (or perhaps does not matter); and
that python-central, or its cognate, saves substantial packager time;
and that the thought process of B) above is not unduely burdensome on
our users (or at least sysadmins); then you have a slam-dunk case.
Otherwise, you are talking about engineering tradeoffs. And I have seen
no numbers, not even back of the envelope calculations, about the impact
of these tradeoffs. And, we clearly have wildly different intuitions on
the impact of these decisions.
That is, I want to know more. Nothing should be made part of policy
because it can be done, not even because it can be easily done. There
has to be an argument that it should be done.
Jim Penny
Reply to: