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

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