[Python-Dev] PEP 376 - Open questions

[Paul Moore]

2009/7/8 Eric Smith <eric at trueblade.com>:
> [Any reason you didn't respond to the list? I'd like to continue the
> discussion there. But I'm currently replying just to you.]

No, I just clicked the wrong button. Sorry. Redirecting back to the list.

> Paul Moore wrote:
>>
>> 2009/7/8 Eric Smith <eric at trueblade.com>:
>>>
>>> I agree with this. For RPM's, there's a whole other database of what
>>> files
>>> were installed. Is it really the intent that a file will be managed by
>>> multiple different installers? That I can install with RPM but remove
>>> with
>>> some python-installer (or other) tool? That way lies madness. In fact, I
>>> see
>>> RECORD as an installer-specific detail that doesn't need to be
>>> standardized
>>> at all.
>>
>> I thought RECORD was to ensure that you can install with RPM, and
>> *not* have any other random uninstaller remove your files (because you
>> populate RECORD, and the other uninstaller uses
>> pkgutil.get_file_users(path) to find out that you care about the file,
>> and hence avoid deleting it).
>
> I really don't think this is a use case worth supporting. A single file
> managed by multiple installers is a mess waiting to happen. RPM won't let
> you do it. About the only use case I can think of is namespace packages, and
> that can be handled by factoring out the __init__.py file into it's own
> install package.

Personally, I think you're right. But I have essentially zero
experience with the non-Windows use cases, so I don't feel qualified
to judge.

It seems to me that a lot of the fancy detecting what other people do
stuff is motivated by setuptools. I'm not going to comment on that,
other than to say that it may be that setuptools is generating more
problems than it's solving...

>> Basically, other install methods can't read your (RPM) database, and
>> you can't read their database. RECORD is a simple common format,
>> providing just enough information for everyone to communicate the
>> message "I manage this file".
>
> The RPM uninstaller won't look at the RECORD file. I think the best we can
> say is that _if_ an installer wants to share state about what's installed
> with other installers, this is how it's done.

OK. I'd be stunned if bdist_wininst or bdist_msi ends up checking RECORD.

So that's 3 "not interested" votes.

Who's going to use the APIs based around the RECORD file? Anyone?

Seriously - who is actually going to USE any of the APIs being
proposed in PEP 376? If no-one's interested, we should stop right now.
Do any of the people from the summit read this list? If not, can
anyone contact them and get some feedback?

Paul.