[Pythonmac-SIG] Pack Man issues on OS X 10.3.4

[Kevin Ollivier]

Hi Ronald,

On Jun 9, 2004, at 7:56 AM, Ronald Oussoren wrote:

>
> On 7-jun-04, at 14:38, has wrote:
>
>> Bob Ippolito
>>
>> [snip 'Bill Cosby' moment]
>>
>>> PackageManager was designed to have as simple of an *implementation* 
>>> as possible, and it pretty much does.  You do a lot of hand-waving 
>>> about how awful it is, but the reality is that it is VERY simple and 
>>> works pretty well.  The GUI application is horrible and has lots of 
>>> bugs, but that is easy to fix.  The underlying system doesn't have 
>>> very many real problems.
>>
>> My problem isn't that it's inherently awful, it's that it's 
>> inherently pointless. 1. Expending 100% of labour creating a solution 
>> that caters to <1% of module installations if not an efficient use of 
>> extremely scarce, and therefore extremely valuable, manpower and 
>> brainpower resources (i.e. yours, Jack's and the other core MacPython 
>> developers). 2. Its administration model is inherently non-scalable, 
>> being utterly dependent on the good will and hard work of a few elite 
>> MacPython gurus to maintain its custom databases.
>
> PackMan tries to provide an easy to use interface for installing 
> *tested* packages. I hope it
> will grow an easy to use interface for maintaining a database and for 
> doing coopereative management of the database. The debian projects 
> seems to manage this just fine for an entire
> Linux distribution :-)

Yes, but that's because they've got a good number of people using 
Debian testing/unstable. If they had no one testing packages, and had 
to QA all packages with no help from the outside world, their stable 
packages would probably be based on even older packages than it is now. 
;-) The point, IMHO, is that while a few gurus can maintain "the 
database" and make sure all contributions are on the up-and-up, I'm not 
sure it's a good idea to put all the work of developing packages, 
testing and QA on their shoulders alone, as they can't test on a very 
large number of machines and we'll end up having so few QA packages 
that it won't really be much of a Package Manager. Instead, there 
should be a "testing" or "unstable" branch built into PM (which people 
can enable after clicking yes to an "ARE YOU SURE!?" type of dialog) so 
that people like myself can install packages, report any problems, and 
not have to wait until everything is QA'd to use it. I'll be happy to 
test a package if it means getting access to the package faster, and by 
all accounts, this strategy ensures a lot of package testing for the 
Debian folks.

So I don't think it means we'll end up with a bunch of "non-QA'd" 
packages in the database, rather, the packages would get QA'd faster. 
Build/install problems are caught by the software itself, so the error 
could be forwarded directly to the "scapegoat" along with the version 
of Python/OS X they are using, and I think that would actually speed up 
the diagnosis and resolution of problems. We could also implement ways 
of keeping track of the number of successful installs on Jaguar, 
Panther, etc.

BTW, as for the interface, for the Windows/Linux version of PackMan (I 
guess Mac will be using Cocoa), I plan on providing a GUI wrapper to 
Bob's buildpkg script so that people can "submit" packages for 
inclusion into the database, and once a scapegoat properly ensures the 
package installs on their machine, it goes into the "testing/unstable" 
branch. I think this would encourage more contributions and help build 
the database. Hopefully I will have more time to do contributions now 
that summer is here and I have *finally* finished my schooling. ;-) But 
we need to get wxPython 2.5.2 out first, which should be in the next 
week or two.

> What you seem to forget is that there is a difference between theory 
> and practice. In theory
> installing a package is as easy as 'tar zxf some-packaget.tgz && cd 
> some-package && python setup.py install'. In practice, there are a 
> number of interesting packages where you have to modify setup.py or 
> some other configuration file before you get a working installation.
>
> An anecdote from the real world: this morning I tried to install the 
> perl BerkelyDB package on a Solaris machine at work. The obvious way 
> to do this is "perl -MCPAN -e 'install BerkelyDB'", but that didn't 
> work because it's config.in contained data that didn't work on this 
> particular machine.

This is exactly why I think we need a testing/unstable branch to find 
and work out the "corner cases". Of course, making a package work on 
Panther or Jaguar alone provides a more homogeneous environment that 
needs less testing, but we should still be mindful of the various ways 
in which people configure their machines. (Off hand, I can think of 
library conflicts due to other versions of libraries installed as well, 
etc.) QA'd packages should only blow up if the user REALLY mucked up 
their machine, but it should at least provide warnings for problems 
with alternative configurations.

[snip]

> The hardware engeneering folks are very serious about creating working 
> stuff, I suppose programmers get inspired by that (why else would we 
> have the misnomer software engeneering?).
>
> BTW. PyPI isn't very useful as a component of a larger system (at 
> least not at the moment). It doesn't seem to have a UI for querying it 
> programmaticly, there are no links to downloadable archives (neither 
> source nor binary), .... Fixing those issues is at least as much work 
> as fixing PackMan, that's without considering the "politics" that 
> would be needed to get those changes accepted.

There is room for integration, though, and I think we should visibly 
integrate with PyPI if only for political reasons. =) It would show 
some goodwill to show we're not really trying to step on the work of 
others. In the end, I see it as providing a web-based interface to 
PackMan. Source and Binary "links" could be made that fire up PackMan 
and have it start fetching the package you clicked on.

Thanks,

Kevin