[Pythonmac-SIG] What is the future of Python on OSX?
Kevin Ollivier
guess-who@kevin-masako.com
Sat, 7 Sep 2002 20:56:52 -0400
On Saturday, September 7, 2002, at 05:58 PM, Jack Jansen wrote:
>
> Kevin Ollivier wrote:
>> I've been thinking about that myself. The database could actually be
>> run off the web and output an XML file which the Python Install
>> Manager client software would read.
>
> That would definitely be the most sensible approach. We have all the
> tools to download and parse XML, after all. And we get a versioning
> scheme whereby we can keep things simple initially and extend our DTD
> later when we understand the problems better.
>
>> Making it web-based would enable the developers themselves to go
>> online and add their package information to the repository.
>
> I think that initially I would like to go with a centralized scheme,
> i.e. appoint one (or a few) people responsible for the database. I
> also think that we should initially aim for something that supports
> the major packages (pyobjc, tkinter, wxpython, numeric, opengl, pil,
> piddle and maybe a few more), and that the Database Czar is morally
> responsible for testing the installers before putting them in the
> database.
>
>> For the more complicated stuff, we could let the developer specify
>> "pre" and "post" install scripts for dependencies without bloating
>> the database format. We could also work on getting it hosted by the
>> PSF on python.org, that way ensuring that it will be maintained.
>
> Again, I think we should slow down a little here. If at first we aim
> for MacOSX only we can learn some lessons that we can then apply to a
> generalized Searchable Python Archive of Modules. Yes, that name is
> brilliant, it makes you wonder why the perlies put up with CPAN:-)
>
> Mirroring and such (as Alexandre mentioned) I think we should also put
> off to a later date. It's very easy to add on. Same for things like
> digital signatures and version verification (which you definitely want
> when you do mirroring). And for a SPAM we'll also need to address
> multiplatform issues, source/binary, searchability on keywords
> (otherwise SPAM won't work:-0) and more like that. And if we allow any
> developer to enter stuff into the database we need a feedback scheme
> on what has been known to work on what platform, etc.
Didn't mean to get ahead of things here, just throwing out some ideas.
=) I think you're right that the best way is to first add it into the
Mac distro and get some good testing in first.
As for feedback, I think a simple way to add this is to give each
package a "comments" section, kinda like what the PHP online manual
does. I've actually found the comments there quite helpful in
diagnosing and working around some Windows/IIS specific bugs.
> And I have this pet feature I want to add (but at a much later date):
> a list of modules/packages that the package will provide when
> installed. That way, if you get an obscure script from someone that
> does "import foobar" the IDE could catch the import error and point
> you in the direction of the package you might want to install.
>
> Let me take a shot at an initial database format. I'm making this up
> as I go, so there's probably holes in it. The XML file has a head
> section with the DTD and version and other mumbo-jumbo, and the body
> is a list of packages. A package consists of a name, a version, a
> one-line description, a URL at which the user can find out more
> information, a list of dependencies, an existence test script and an
> install script.
>
Don't know if I'm getting too detailed at this early phase, but I'd
suggest that there be a list of categories as well.
> Of these I think only the latter three pose some interesting
> questions. Maybe the list of dependencies shouldn't be a list, but
> also a script, so you can test for specific versions of packages on
> which you depend? That way you could also use gestalt to test for
> specific OS versions or other things outside the control of the Python
> Install Manager, but on the other hand declarative is usually better
> than procedural. But for a first stab it would allow, say, the Tkinter
> dependency script to test whether AquaTk is installed and, if not,
> tell the user to read the "more information" document where you can
> post detailed instructions on how to install AquaTk yourself.
I think the list approach is better because it lets you reuse the
package information you've already entered into the system. My
application, for example, would have PyXML and wxPython as
dependencies. Since those packages would be in the database and have
their own existence test scripts, I would only have to write a script
for my own package and specify that the wxPython and PyXML packages
must pass their existence tests before my package can be installed. For
situations like AquaTK, there could be an "install instructions" field
in the package information.
Just a thought that popped into my head: what about an uninstall
script? Should that be added into the package information?
> And for all three scripts there's the question of whether they're
> included inline or referenced by URL. I lean towards including the
> existence test script inline (so the PIM can quickly show
> installed/not installed status) and having the other two referred by
> URL (because there's no need to load them if the end user couldn't
> care less about a certain package).
This sounds like a good approach to me. When the package database gets
large, having less to load would make a difference as well. =)
> Oh yes, the version information in the head section should not only
> include the database version but also the version of the PIM: if the
> inline scripts are to be of acceptable size then the PIM should setup
> an environment in which the scripts are run (and for instance
> pre-import such goodies as sys, os, string, gestalt, etc).
>
I think a "last updated" date should also be included. Eventually, this
would enable the PIM to warn users that they need to go online and
update their package database when it gets old.
Thanks,
Kevin
> Hmm, and now that I read that AquaTk sentence again I think there are
> actually 4 states in which a package can be (according to the
> existence test script):
> 1. It's not there
> 2. It's there, it's up to date, everything's fine
> 3. It's there, but you have an old version
> 4. It's there but it doesn't work, you've probably messed up some of
> the dependencies or something else is going on that the PIM can't help
> you with.
> --
> - Jack Jansen <Jack.Jansen@oratrix.com>
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma
> Goldman -
>
>
> _______________________________________________
> Pythonmac-SIG maillist - Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>