[Distutils] how to easily consume just the parts of eggs that are good for you

[Stanley A. Klein]

On Fri, April 11, 2008 6:00 am, Dave Peterson <dpeterson at enthought.com>
wrote:

>
> Message: 5
> Date: Thu, 10 Apr 2008 18:16:03 -0500
> From: Dave Peterson <dpeterson at enthought.com>
> Subject: Re: [Distutils] how to easily consume just the parts of eggs
> 	that are good for you
> To: "Phillip J. Eby" <pje at telecommunity.com>
> Cc: distutils-sig <distutils-sig at python.org>

>
> Phillip J. Eby wrote:
>> At 03:48 PM 4/10/2008 -0500, Dave Peterson wrote:
>>> Stanley A. Klein wrote:
>>>> On Wed, 2008-04-09 at 18:17 -0500, Dave Peterson wrote:
>>>>> I think I can sum up any further points by simply asking: "Should it
>>>>> be safe to assume I can distribute my application via eggs /
>>>>> easy_install just because it is written in Python?"
>>>>
>>>> I think that based on this discussion the bottom line answer to this
>>>> question is "No".
>>>
>>> I agree that it seems like that's where things are headed in the
>>> discussion.  But the discussion doesn't always coincide with the
>>> reality, right?   I guess I'm trolling more for a statement from the
>>> setuptools maintainer here.
>>>
>>> Particularly since I'm looking for an answer to my question about
>>> should Enthought continue to invest time into a setuptools patch that
>>> lets developers include docs, config files, etc. in eggs for
>>> installation in a FHS-approved location at install time?
>>
>> I think it's more than reasonable to define a standard for including
>> such data.  I'm somewhat more skeptical about doing that installation
>> automatically within easy_install.  Likewise, I'm skeptical about
>> doing other sorts of non-package, non-script installation.  I'd like
>> to see proposals that show due care to cross-platformness,
>> uninstallability, etc.
>>
>> In other words, when it comes to a "patch" -- the documentation is
>> going to count for a lot more than the code, and I'd rather see a
>> concrete proposal well in advance of the patch.
>>
>> Sooner would be better than later, too, because it's likely that the
>> plan for "non-egg installs" is going to be affected by the plan as well.
>
> I believe I understand, and agree, with your concerns.   Let me be clear
> on the status of where we are in our work:  we've internally talked
> through a number of design possibilities, and are now trying out (via
> hacking on setuptools) how the one we thought was "best" worked out.  In
> particular, we're concerned about the difficulty of use in terms of even
> just the use-cases we have for ETS projects.   Also, since we do a bit
> of cross-platform deployment, we're also investigating those effects on
> the design as well.   That being said, I don't think we're ready to put
> forward a proposal that would withstand too much public scrutiny quite
> yet - at least if the resulting discussion implied a significant time or
> effort commitment on our part to carry the conversation forward.  If it
> sounded like we'd already figured it all out, I apologize for getting
> people's hopes up!   I just wanted to make sure further pursuit in this
> direction on our part wasn't completely wasted.
>
> The above not withstanding, if anyone is interested in talking about it
> / helping us, we certainly wouldn't ignore you.  I just can't promise
> immediate responses due to pretty pressing customer commitments on our
> part.
>
>
> Regarding the mention of 'uninstallability' above, I assume it would be
> sufficient if the installed files were simply included in the generated
> list of files provided by the "--record" option since there is currently
> no uninstall command at all?  Or is there something else you'd like to
> see as an intermediate measure?   I'd love to add an uninstall option to
> easy_install as well (it's something we get hit about alot by our user
> community) but there's only so many hours in a day. ;-)
>

Here are a few principles I think I've gleaned from this discussion:

1.  Eggs are not intended to serve as substitutes for rpms, debs, and
other platform package distribution systems.  They are primarily intended
as a convenience for developers during development.  They can be used in
distribution packaging in a manner analogous to .jar files in java.

2.  Every platform wants to put the files somewhere different. 
Accordingly, Setuptools and Distutils need to support mapping the files to
the preferred locations for the various platforms.

3.  Setuptools and Distutils support some platform packaging systems, such
as rpm.  Packagers should distribute using those systems.  If eggs are
included in a package, they should be treated as any other file for that
packaging system and not as a form of distribution.  For example, an rpm
should reasonably be able to contain egg files along with other
distribution files.  (Note that java-related rpms often contain .jar
files.)  Consideration should be given to adding features to existing
support for platform packaging systems.  Also, if egg files are to be
included in a distribution package, it needs to be a two-step process
(first make the eggs, then make the package).

4.  It would probably help to have a style guide or automated converter
for naming and placement of files in a source distribution to facilitate
file location mappings and platform naming issues.  For example, Windows
accepts file names with spaces in them but Linux generally doesn't (and
bdist_rpm produces errors if it sees them).  For a multiplatform
distribution either a style guide or a lint-type tool needs to address
issues like this.


Stan Klein