Mailing List Archive

Guido van Rossum [guido@CNRI.Reston.VA.US] wrote:
> I think it may be time for separate Python distributions, like Linux
> -- I can concentrate on the core, and keep it really small; others can
> make all-encompassing distributions.

My fear is what we face in the Zope world---different distributions break
in totally diffrent ways, and sometimes we have to ask 30 questions to figure
out what might be going wrong :/ The nice thing is hat if someone installes
Python from the source, we know what's going to happen. I don't know if
this is solvable, honestly.

> This isn't rocket science. Red Hat Python? I'm all for it! :-)

I think Guido just wants to IPO and retire :-)

Chris
--
| Christopher Petrilli
| petrilli@amber.org

Guido van Rossum wrote:
>
> I like the batteries included approach, but I also feel resistence
> against including stuff I cannot maintain.
> ...
> This isn't rocket science. Red Hat Python? I'm all for it! :-)

I think we should wait for distutils to get up and running
perfectly for everyone before taking such a step.

--
Marc-Andre Lemburg
______________________________________________________________________
Y2000: 15 days left
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/

On Thu, 16 Dec 1999, M.-A. Lemburg wrote:
> Guido van Rossum wrote:
> > I like the batteries included approach, but I also feel resistence
> > against including stuff I cannot maintain.

This is an interesting comment, and is similar to the Apache sentiment.
Nothing gets added to the standard distribution unless somebody in the
Group is willing to maintain it. It provides a good mechanism for keeping
the module set to a reasonable size and a set that can/will actually be
maintained.

> > ...
> > This isn't rocket science. Red Hat Python? I'm all for it! :-)
>
> I think we should wait for distutils to get up and running
> perfectly for everyone before taking such a step.

You can also operate on the assumption that it will be done by the time
1.6 is ready to be released. In other words: do the work (distutils and
minimizing the release) in parallel, rather than in sequence.

I would also think that a large distro isn't going to be assembled with
distutils. Somebody will sit down, pull all the components together, and
make a big release.

However, I do see the distutils as being needed for the people who grab
the minimal distro. They need it to grab add'l packages.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

> Guido van Rossum wrote:
> >
> > I like the batteries included approach, but I also feel resistence
> > against including stuff I cannot maintain.
> > ...
> > This isn't rocket science. Red Hat Python? I'm all for it! :-)

MAL:
> I think we should wait for distutils to get up and running
> perfectly for everyone before taking such a step.

Fair enough -- but in the mean time, no more pushing for new modules
in the core distribution (distutils excluded).

--Guido van Rossum (home page: http://www.python.org/~guido/)

On 17 December 1999, Guido van Rossum said:
> Fair enough -- but in the mean time, no more pushing for new modules
> in the core distribution (distutils excluded).

So anyone who wants a new module snuck into the core just has to
convince me to add it the distutils package, right? >snicker<

Greg

>>>>> "GvR" == Guido van Rossum <guido@CNRI.Reston.VA.US> writes:

>> Guido van Rossum wrote: I like the batteries included
>> approach, but I also feel resistence against including stuff I
>> cannot maintain. ... This isn't rocket science. Red Hat
>> Python? I'm all for it! :-)

>> MAL wrote:
>> I think we should wait for distutils to get up and running
>> perfectly for everyone before taking such a step.

GvR> Fair enough -- but in the mean time, no more pushing for new
GvR> modules in the core distribution (distutils excluded).

Perhaps the right long-term solution (post-distutils) is to split
Python into a core architected by Guido and a bazaar-style standard
library maintained in a more apache-style.

Jeremy

Recently, Jeremy Hylton <jeremy@cnri.reston.va.us> said:
> Perhaps the right long-term solution (post-distutils) is to split
> Python into a core architected by Guido and a bazaar-style standard
> library maintained in a more apache-style.

I can't help feeling uncomfortable with this. I've had quite some work
to get an Apache with SSL up and running, even though someone gave me
quite precise instructions. With Perl I fared even worse, despite
their distutils-like package, when I wanted to try a PalmPilot package
for Unix that needed Perl. I finally had to give up after quite some
effort because the addon installers kept finding the older version of
Perl that the system mgr had installed in stead of my newer version.

I think distutils will be wonderful for us, the Python community, but
something more RedHattish is needed for the general world who just want
Python plus a certain set of extensions because some application needs
it, so they can just download a fresh copy of ParrotPython 3.4.4 and
know the application will work, without interfering with another
application that happens to use Inquisition 1a5 and lives elsewhere on
the disk.

And maybe the answer is a much simpler freezing process, like
MacPython BuildApplication where any Python user can drop a script on
it and end up with a fully self-contained app guaranteed (well.... No
reports to the contrary have been heard so far, at least:-) to contain
everything needed and not interfere with an existing MacPython
installation (or be interfered with by it). Then a popular app will
have prebuilt binaries available for all platforms quickly, made by
the Python community, and the enduser interested in the app but not in
Python can simply download that.

--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

Jack Jansen wrote:

> And maybe the answer is a much simpler freezing process, like
> MacPython BuildApplication where any Python user can drop a script on
> it and end up with a fully self-contained app guaranteed (well.... No
> reports to the contrary have been heard so far, at least:-) to contain
> everything needed and not interfere with an existing MacPython
> installation (or be interfered with by it). Then a popular app will
> have prebuilt binaries available for all platforms quickly, made by
> the Python community, and the enduser interested in the app but not in
> Python can simply download that.

IMHO the "much simpler freezing process" is archive files. A simple
script can build them, imputil can import them, and the only
remaining problem is to find them. Please see:

ftp://ftp.interet.com/pub/bootmodule.html
ftp://ftp.interet.com/pub/pylib.html

JimA

> IMHO the "much simpler freezing process" is archive files. A simple
> script can build them, imputil can import them, and the only
> remaining problem is to find them. Please see:

Archive files solves the problem for Python modules. But that leaves the
problem of dynamically loaded modules. And resources for dialogs and such, if
you use native GUI stuff on Mac or Windows.

And most serious applications that I've seen (GRiNS and Zope, to name two,
Mailman is the only exception I can think of) depend on non-standard plugin
modules.
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

Jack Jansen wrote:

> Archive files solves the problem for Python modules. But that leaves the
> problem of dynamically loaded modules. And resources for dialogs and such, if
> you use native GUI stuff on Mac or Windows.

Point taken.

For dynamically loaded modules, I believe in following the
native system's DLL path, and not adding eccentric Python
logic. But many disagreed a couple week's ago when I raised this.

For resources, I think the archive file can accommodate this,
although it seems highly system dependent.

Anyway, any file at all can live in the archive and the import
mechanism for *.pyc will not be damaged nor unduly slowed down
by its presence.

JimA