My view is that a software package should not distribute and install its own dependencies. I think matplotlib should have a list of dependencies (Python 2.2+, Numeric or numarray, ...) which it requires before it attempts an install, and a list of optional dependencies (pytz, dateutil, ...) which matplotlib supports if it finds they are already installed. Regards, Steve
On Tue, 2004年09月21日 at 19:44, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> My view is that a software package should not distribute > Steve> and install its own dependencies. I think matplotlib > Steve> should have a list of dependencies (Python 2.2+, Numeric or > Steve> numarray, ...) which it requires before it attempts an > Steve> install, and a list of optional dependencies (pytz, > Steve> dateutil, ...) which matplotlib supports if it finds they > Steve> are already installed. > > What's your argument for this? My argument is that most other software I've looked at does this and it seems to work OK. I guess the reasons are that - it makes software packages smaller - you only need to directly download one copy of a package and do not indirectly download multiple copies of the same package. - you can end up with multiple versions of a package. And later you may try to recall - which package x did I use to install package y? - the software package that includes other packages needs to make sure it keeps up to date with with the included packages and does not install old versions. > My motivation to include them is mainly to simplify the install > process, to have some control over versioning, and to simplify the > coding process. Since these are pure python packages, they present no Yes, this is an advantage of including everything, and a disadvantage for minimal packages. > Does your opinion change for the win32 installer? In that case, we > also include freetype, libpng, zlib. I guarantee the numbers of win32 > users would drop significantly if they had to install these extra > packages. Neither dateutil nor pytz distribute a win32 installer. > dateutil doesn't include a zip file (only a tar.bz file). So win32 > users would first have to get bunzip2, and then tar, figure out how to > use them, install, etc, just to get matplotlib date support. Win32 could be a special case. As a way to encourage more users how about working towards moving from the development status of version 0.62.4 "4 - Beta" to 1.0.0 "5 - Production/Stable". What's the criteria for this step? My understanding is that it does not mean that all desired features are implemented or complete, it just means that the software is stable, and matplotlib seems to be pretty stable already. Regards, Steve
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> My argument is that most other software I've looked at does Steve> this and it seems to work OK. I guess the reasons are that Steve> - it makes software packages smaller - you only need to Steve> directly download one copy of a package and do not Steve> indirectly download multiple copies of the same package. - Steve> you can end up with multiple versions of a package. And Steve> later you may try to recall - which package x did I use to Steve> install package y? - the software package that includes Steve> other packages needs to make sure it keeps up to date with Steve> with the included packages and does not install old Steve> versions. Hi Steve, Those are reasonable arguments. I'm still convinced that it is better to err on the side of simplifying the install, though. matplotlib has been distributing some of it's prereqs for some time (agg, pyparsing) and not others (Numeric/numarray, freetype, libpng). I try to balance the likelihood the user already has the package on their system, the additional ease/complexity of installation and coding, and package size. On balance, I decided to add pytz and dateutil to the matplotlib src distro - I won't however, overwrite existing installs. In the past we've included things (fontutils, ttfquery) that were eventually removed because we found or wrote better replacements. So the matplotlib package size tends to fluctuate up and down a bit. Currently, with src, fonts, icons, examples, example data, and add-on packages, the src dist comes to 1.6M. I can live with that. Steve> As a way to encourage more users how about working towards Steve> moving from the development status of version 0.62.4 "4 - Steve> Beta" to 1.0.0 "5 - Production/Stable". What's the Steve> criteria for this step? My understanding is that it does Steve> not mean that all desired features are implemented or Steve> complete, it just means that the software is stable, and Steve> matplotlib seems to be pretty stable already. I'm amenable. Do you know of instances where people aren't using matplotlib due to it's version number or development status flag? My working plan is to be mostly 2D feature complete for 1.0, but I am not wed to this. As you say, 1.0 really just implies some stability rather than feature set. The only thing off the top of my head that must be added before 1.0 is a Users Guide - I should be done with this already, but alas... Should be done in a month (I said that last month) I also think it would also be nice to have a more streamlined, sophisticated configure process. The other core features that would be nice to have but aren't absolutely critical are polar and contour. I believe the stsci folks are working on contour. As for stability, there will probably be a significant refactoring of the renderer drawing API at some point. But I don't think this precludes a 1.0 release. As long as the matlab interface and OO Figure/Axes/Text/Line/Patch interface is stable, and it largely is discussed on the user's list), then I don't think it would break any existing code to refactor the drawing model down the road. As far as I know, noone is directly using the renderer API, and I've never advertised it. JDH
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> My view is that a software package should not distribute Steve> and install its own dependencies. I think matplotlib Steve> should have a list of dependencies (Python 2.2+, Numeric or Steve> numarray, ...) which it requires before it attempts an Steve> install, and a list of optional dependencies (pytz, Steve> dateutil, ...) which matplotlib supports if it finds they Steve> are already installed. What's your argument for this? My motivation to include them is mainly to simplify the install process, to have some control over versioning, and to simplify the coding process. Since these are pure python packages, they present no extra installation overhead for matplotlib and the only downside I see is potential package bloat. Both of these packages combined add 200k to the src distro. The coding burden is reduced, if for example I know pytz is included, because I don't have to do a lot of conditional stuff throughout the code where that module is used. Does your opinion change for the win32 installer? In that case, we also include freetype, libpng, zlib. I guarantee the numbers of win32 users would drop significantly if they had to install these extra packages. Neither dateutil nor pytz distribute a win32 installer. dateutil doesn't include a zip file (only a tar.bz file). So win32 users would first have to get bunzip2, and then tar, figure out how to use them, install, etc, just to get matplotlib date support. Basically, my goal is to maximize the likelihood that someone can use matplotlib even if they haven't RTFM. I wish they would read the install instructions and dependencies, but I think that is only about half of the users. If we can set it up so that most things work out of the box on a standard python setup - and I think having Numeric/numarray) is fairly standard for most potential matplotlib users. On a related note, Todd just added a fix in CVS that autodetects numerix at build time and builds in Numeric and/or numarray. It would probably be a good idea to have an rc template and write the actual rc file depending on what the autodetect finds in setup.py. Eg, if setup finds Tkinter and numarray but not pygtk and Numeric, there's not much sense in using the default backend : GTKAgg and numerix : Numeric in rc. Paul did something like this for the license, so that the license file was automatically built with the correct version number at build time. JDH
John Hunter wrote: >>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes: >>>>>> >>>>>> > > Steve> My view is that a software package should not distribute > Steve> and install its own dependencies. I think matplotlib > Steve> should have a list of dependencies (Python 2.2+, Numeric or > Steve> numarray, ...) which it requires before it attempts an > Steve> install, and a list of optional dependencies (pytz, > Steve> dateutil, ...) which matplotlib supports if it finds they > Steve> are already installed. > >What's your argument for this? > >My motivation to include them is mainly to simplify the install >process, to have some control over versioning, and to simplify the >coding process. > I agree with JDH on this one. Including extra pure-Python packages is not likely to cause (m)any problems: 1) on systems where people do lots of "python setup.py install" the definitive list of installed packages is the contents of site-packages 2) on systems with real package managers (e.g. Debian), this is for the package maintainer to worry about. those extra packages should be made package-level dependencies and not in the matplotlib.deb itself. (this assumes people on these systems are using the package manager. if not, see point #1) 3) on Windows, you want to double click something that just works. (In fact, by this reasoning, there's nothing against including mixed C/Python packages, either.)
On Tuesday 21 September 2004 11:54 am, Steve Chaplin wrote: > My view is that a software package should not distribute and install its > own dependencies. > I think matplotlib should have a list of dependencies (Python 2.2+, > Numeric or numarray, ...) which it requires before it attempts an > install, and a list of optional dependencies (pytz, dateutil, ...) which > matplotlib supports if it finds they are already installed. I second that. -- Darren Dale