[Pythonmac-SIG] Package Manager idea, adding a URL scheme

[Bob Ippolito]

On Wednesday, Oct 1, 2003, at 16:04 America/New_York, Ronald Oussoren 
wrote:

>
> On 1 okt 2003, at 21:39, Bob Ippolito wrote:
>
>>
>> On Wednesday, Oct 1, 2003, at 15:33 America/New_York, Ronald Oussoren 
>> wrote:
>>
>>>
>>> On 1 okt 2003, at 21:23, Bob Ippolito wrote:
>>>
>>>>>
>>>>> That won't work whenever we get around releasing pyobjc-1.0, as 
>>>>> "1.0" < "1.0b1" :-(.
>>>>
>>>> We need to standardize on a way to do this, obviously..  The string 
>>>> comparison thing is bad, and the scapegoat has to figure out how to 
>>>> find the version for each package (which isn't always possible, 
>>>> because not every package includes this metadata).
>>>>
>>>> There should be a standard sys.version_info way of getting package 
>>>> versions.
>>>
>>> Not necessarily. It would be nice if every package used the same 
>>> layout of the version string (maybe the scheme used by python 
>>> itself), but the Linux package manager seem to have an pretty 
>>> accurate heuristic for comparing versions. Borrowing that heuristic 
>>> would also work.
>>
>> Can you find a reference for this?  I'm not even sure which Linux 
>> package manager you're referring to.
>
> I don't have a reference at hand, but I'm pretty sure RPM generally 
> "does the right thing" with version numbers. I haven't built linux 
> packages for years though, after I switched to Debian on my Linux 
> machine I haven't felt the need to built packages.

I'd be willing to guess that RPM generally "does the right thing" with 
version numbers, because the developers that make then generally 
"provide the right information" to the build tools :)  Python 
developers currently do not have a real standard way of choosing 
version numbers and they definitely do not put the version number 
anywhere standard in their modules and packages.

>>
>>> BTW. I just noted that PackMan (the GUI) doesn't have an 'uninstall' 
>>> option. That makes it harder to throw away packages that are not 
>>> really needed.
>>
>> You would either need to keep receipts, or the scapegoat would have 
>> to maintain an "uninstall program" for each package.  Receipts is 
>> probably the way to go here, and that would at least partially solve 
>> the version-number-string problem (because the scapegoat wouldn't 
>> necessarily have to maintain a version checker for each package, but 
>> that would be incompatible with packages that the user installed 
>> themselves unless distutils was modified to support receipts).
>
> I don't see how receipts would help with the version-number problem, 
> other than making it easier to find a version number. Distutils also 
> creates a PKG-INFO file in the source-distribution, that's an easy 
> source for information about packages (to bad this isn't installed 
> when you install a package).

Having an installed PKG-INFO file would be awesome, but how would this 
accommodate non-package installs unless the PKG-INFO file was part of a 
receipt that got stashed somewhere?  Personally I think anything 
installed in site-packages should be a package in the first place, even 
if it has an __init__ that says from module import *.

> I don't think that adding receipts to PackMan would be usefull, unless 
> the end-goal is pushing that code into distutils/the python core.

Receipts are the only reasonable way to do uninstallation and would let 
us do version checking without running arbitrary Python code (which I 
really don't like, mixing metadata with code).

-bob