Your search query "linkto%3A%22MacPython%2FNewPackageManager%22" didn't return any results. Please change some terms and refer to HelpOnSearching for more information.
(!) Consider performing a full-text search with your search terms.

Clear message

Notes about what we need to do

Also see:

Extending PEP-241 ( )

As per Sarwat's suggestion for canonical version numbers, we do have somewhat of a solution that I was unaware of: the StrictVersion and LooseVersion classes in distutils.version. LooseVersion will pretty much allow us to compare arbitrary 1.0a2 vs 1.0b2 version numbers reliably. If they don't compare reliably or can not be parsed by LooseVersion, the package author is not following spec and should be smacked around :)

We need more metadata, here's what we need:

I believe this will be sufficient. However it may be nice to be able to specify C or C++ libraries that a package wraps or depends on (but does not include). Ideas?

One thing, related to Package-Name, is that we should completely deprecate the practice where you can install a whole bunch of python modules flat in site-packages. If you have more than one file that belongs in site-packages, it should go in a separate folder and be referenced by a pth file. There should be a 1:1 relationship between the number of modules+packages in your site-packages, and the number of modules+packages that you installed.

Discussion of PEP-243 ( )

PEP-243 proposes a central module repository system for source modules. We should say that the PackMan system will supplant this because (a) it could take advantage of a central module repository if available and (b) it's easier these days to host open source projects anyways (a la sourceforge). Speaking of sourceforge, we should have special integration for sourceforge downloads in PackMan (let the user choose a preferred mirror, display to the use who is sponsoring their download). It's possible that the scapegoat may choose to come to an arrangement with the package maintainers such that package maintainers will host the scapegoat-built binary packages on their site to make it more economical for scapegoats.

Embrace and Extend PEP-262 ( )

PEP-262 is the holy grail for PackMan, it allows us to develop a sane way to do package management, especially uninstallation.

For our platform, PEP-262 has one inherent deficiency: INSTALLDB (the location for receipts) is a fixed location and not a search path. I propose that we leverage sys.path in our quest to locate the installation receipt database, that way we can find /System/Library/... /Library/... /Network/Library/... ~/Library/... or whatever is appropriate for that particular installation of Python. The installation database could have a file name that would be unacceptable as a python package name, such as INSTALL-DB, this way it could not possibly be confused with an actual package.

I think that we can deprecate the REQUIRES and PROVIDES files by adding Depends, Package-Name, and Recommends to PKG-INFO. I don't think that the "PROVIDES" file makes a whole lot of sense, unless the strings used in provides means it corresponds to a definitive module interface. There is not currently any sort of registry or PEP for this kind of thing, so it's probably not at all useful. Since we have upgraded PEP-241, we should also upgrade the Package class in PEP-262 to include the new metadata.

Notes for NewPackageManager

Notes for NewPackageManager GUI

Bug and Feature Requests

The current PM has faulty scrolling---if a pimp site has a package list that is longer than the viewing area, one cannot scroll to see the extra content (well, you can scroll, but the window pops right back to the top). Packages are accessible via the arrow keys, but the faulty scrolling is clearly a bug. Make sure the new manager gets tested on a site with a long list of packages.

The following requests are motivated by those of us maintaining multiple systems, one or more of which have slow net connections. These requests have been echoed by at least one other user on the Pythonmac-SIG, so I suspect many would make use of such features.

First, I'd love to see package size information in the PM window. This way I can tell if it's realistic to download a package to a machine with a dialup connection.

Second, I'd love to see useful progress info on the download and installation. If I check Verbose, the current PM tries to produce this, but unfortuately the resulting text window update is too slow and I'll typically not see any of the progress lines until the download is complete, at which point the window happily shows me every status line from the start to 100%.

Finally, I'd love for there to be a way to save a package locally in a way allowing it to be moved to another machine and installed via PM there. (This would also be useful for backup purposes, so one could restore a particular Python setup.) Ideally I'd like to grab the packages on my fast-connection machine, and install them on the slow-connection machine.

Unable to edit the page? See the FrontPage for instructions.