distutils and Debian

The distutils download page has:
--------------------------------------------------------
Current stable release

The current stable release is Distutils 1.0.2; you can download it as:

* Distutils-1.0.2.tar.gz (source distribution) (233k)
* Distutils-1.0.2.zip (source distribution) (274k)
* Distutils-1.0.2.win32.exe (Windows installer) (187k)

If you are running Python version 1.6 or later, you do not need to
download the Distutils: they're included with Python. However, if you
have a Distutils more recent than your Python, you might want to install
it: see the Distutils README.txt file. Version 1.0.2 is identical to the
version included in Python 2.1.
---------------------------------------------------------

With Debian, it seems that distutils is not included for
Python 2.2 or 2.3.

Should this be reported as a Debian bug?

Colin W.

Colin J. Williams

On Wed, 10 Nov 2004 19:08:09 -0500, Colin J. Williams <> wrote:
> The distutils download page has:
> --------------------------------------------------------
> Current stable release
>
> The current stable release is Distutils 1.0.2; you can download it as:
>
> * Distutils-1.0.2.tar.gz (source distribution) (233k)
> * Distutils-1.0.2.zip (source distribution) (274k)
> * Distutils-1.0.2.win32.exe (Windows installer) (187k)
>
> If you are running Python version 1.6 or later, you do not need to
> download the Distutils: they're included with Python. However, if you
> have a Distutils more recent than your Python, you might want to install
> it: see the Distutils README.txt file. Version 1.0.2 is identical to the
> version included in Python 2.1.
> ---------------------------------------------------------
>
> With Debian, it seems that distutils is not included for
> Python 2.2 or 2.3.
>
> Should this be reported as a Debian bug?

No.

It's in the python2.x-dev packages.

Debian often split large things up into smaller packages, distutils
isn't needed by the basic debian user who only installs debian
packages after all.

"apt-cache search distutils" finds it easily enough for those who do
want it.

--
Sam Holden

Sam Holden

Sam Holden wrote:


>>Should this be reported as a Debian bug?

> No.

I would say yes ... there is no logic in crippling
a standard python distribution. What else is missing?

Istvan.

Istvan Albert

Istvan Albert wrote:
> Sam Holden wrote:
[Colin J. Williams wrote:]
>>> Should this be reported as a Debian bug?
>
>
>> No.
>
>
> I would say yes ... there is no logic in crippling
> a standard python distribution. What else is missing?

It's a matter of Debian policy to split things into runtime packages and
development packages. A Debian package that needs Python to run need
only depend on the main python package. Most packages that need Python
*don't* need distutils or the C headers or the static library.

Debian users know, or ought to, that if they want to compile
extra-Debian software that needs Python (or whatever) they need to
install the appropriate *-dev packages.

This is a pretty standard split thats followed by several free UN*X
distributions (I'm tempted to say "most" but I don't have personal
experience with enough to do that).

--
Robert Kern


"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Robert Kern

On Wed, 10 Nov 2004 20:03:51 -0500,
Istvan Albert <> wrote:
> Sam Holden wrote:
>
>
>>>Should this be reported as a Debian bug?
>
>> No.
>
> I would say yes ... there is no logic in crippling
> a standard python distribution. What else is missing?

If it's anything like perl then lots of things. But they
are easily installed via their seperate packages.

The documentation being the big obvious thing.
Tkinter being another.

The logic might be to make small installs possible. If all
of "standard python" was put in one package then debian
couldn't use python for writing things which might be
wanted on small systems.

It might also make sense to split "pure python" and "binary"
packages up since the "pure python" packages might be sharable
across architecures, but I don't think that is done.

"no logic" seems a bit extreme. Cost exceeding the benefit
might be true, but of the top of my head there's two vaguely
"logical" reasons.

--
Sam Holden

Sam Holden

Robert Kern wrote:

> only depend on the main python package. Most packages that need Python
> *don't* need distutils or the C headers or the static library.

The *devel* branch in my interpretation means the distribution
that contains the files used during the development of the
application itself. For example the C headers
that you mention.

But it should not mean removing support
for installing new scripts for the runtime
application!

Distutils is primarily about installing and distributing
python programs and it has little to do with developing
python itself. Some packages will not
be installable without the devel branch but removing
distutils to head off that situation seems very odd.

Istvan.

Istvan Albert

Istvan Albert wrote:
> Robert Kern wrote:
>
>> only depend on the main python package. Most packages that need Python
>> *don't* need distutils or the C headers or the static library.
>
>
> The *devel* branch in my interpretation means the distribution
> that contains the files used during the development of the
> application itself. For example the C headers
> that you mention.

But in Debian's consistent interpretation, it means "for development
*with* the library/interpreter/whatever." If I want to compile a C
program, I need to install libc6-dev. If I want to *develop* glibc, I
get the source. Similar strategies are employed by other free Unices'
package systems.

> But it should not mean removing support
> for installing new scripts for the runtime
> application!

If I want to compile a non-Debian program that uses libpng, I install
libpng-dev. If I want to install a non-Debian Python package, I install
python-dev. <shrug>

> Distutils is primarily about installing and distributing
> python programs and it has little to do with developing
> python itself.

And as I said, your interpretation has nothing to do with the way Debian
and other Linux/BSD/what-have-you distributions use the suffix in their
package names.

> Some packages will not
> be installable without the devel branch but removing
> distutils to head off that situation seems very odd.
>
> Istvan.

--
Robert Kern


"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Robert Kern

Sam Holden wrote:
> On Wed, 10 Nov 2004 19:08:09 -0500, Colin J. Williams <> wrote:
>
>>The distutils download page has:
>>--------------------------------------------------------
>>Current stable release
>>
>>The current stable release is Distutils 1.0.2; you can download it as:
>>
>> * Distutils-1.0.2.tar.gz (source distribution) (233k)
>> * Distutils-1.0.2.zip (source distribution) (274k)
>> * Distutils-1.0.2.win32.exe (Windows installer) (187k)
>>
>>If you are running Python version 1.6 or later, you do not need to
>>download the Distutils: they're included with Python. However, if you
>>have a Distutils more recent than your Python, you might want to install
>>it: see the Distutils README.txt file. Version 1.0.2 is identical to the
>>version included in Python 2.1.
>>---------------------------------------------------------
>>
>>With Debian, it seems that distutils is not included for
>>Python 2.2 or 2.3.
>>
>>Should this be reported as a Debian bug?
>
>
> No.
>
> It's in the python2.x-dev packages.
>
> Debian often split large things up into smaller packages, distutils
> isn't needed by the basic debian user who only installs debian
> packages after all.
>
> "apt-cache search distutils" finds it easily enough for those who do
> want it.
>
Thanks for pointing this out, but I have checked and Python2.3.4-dev is
installed.

Colin W.

Colin J. Williams

Robert Kern wrote:
> Istvan Albert wrote:
>
>> Sam Holden wrote:
>
> [Colin J. Williams wrote:]
>
>>>> Should this be reported as a Debian bug?
>>
>>
>>
>>> No.
>>
>>
>>
>> I would say yes ... there is no logic in crippling
>> a standard python distribution. What else is missing?
>
>
> It's a matter of Debian policy to split things into runtime packages and
> development packages. A Debian package that needs Python to run need
> only depend on the main python package. Most packages that need Python
> *don't* need distutils or the C headers or the static library.
>
> Debian users know, or ought to, that if they want to compile
> extra-Debian software that needs Python (or whatever) they need to
> install the appropriate *-dev packages.
You are right, but there is a learning curve for those of us new to Linux.

I have installed the Python*-dev packages, but my present problem
centres on installing distutils.

With >python setup.py install, I get:
Traceback (most recent call last):
File "setup.py", line 30, in ?
packages = ['distutils', 'distutils.command'],
File "/root/downloads/python/Distutils-1.0.2/distutils/core.py", line
102, in setup
_setup_distribution = dist = klass(attrs)
File "/root/downloads/python/Distutils-1.0.2/distutils/dist.py", line
130, in __init__
setattr(self, method_name, getattr(self.metadata, method_name))
AttributeError: DistributionMetadata instance has no attribute 'get___doc__'

I would welcome any suggestion as to how I can work around this.

Colin W.

Colin J. Williams

Istvan Albert wrote:
> Robert Kern wrote:
>
>> only depend on the main python package. Most packages that need Python
>> *don't* need distutils or the C headers or the static library.
>
>
> The *devel* branch in my interpretation means the distribution
> that contains the files used during the development of the
> application itself. For example the C headers
> that you mention.
>
> But it should not mean removing support
> for installing new scripts for the runtime
> application!
>
> Distutils is primarily about installing and distributing
> python programs and it has little to do with developing
> python itself. Some packages will not
> be installable without the devel branch but removing
> distutils to head off that situation seems very odd.
>
> Istvan.
I'm inclined to agree with this.

Colin W.

Colin J. Williams