On Thu, Nov 12, 2009 at 12:24 AM, Wolodja Wentland
wentl...@cl.uni-heidelberg.de wrote:
The FHS differentiates between various classes of files and defines
proper location for them. We could define platform dependent
standard infixes for the following data file classes for distribution
foo:
On Fri, Nov 13, 2009 at 18:22 +0900, David Cournapeau wrote:
On Thu, Nov 12, 2009 at 12:24 AM, Wolodja Wentland
wentl...@cl.uni-heidelberg.de wrote:
The FHS differentiates between various classes of files and defines
proper location for them. We could define platform dependent
standard
On Fri, Nov 13, 2009 at 7:38 PM, Wolodja Wentland
wentl...@cl.uni-heidelberg.de wrote:
Could you elaborate on this idea please? Do you mean that megabars
plugins are shipped in a different distribution than megabar itself?
Yes. Imagine that I create a library, which includes a firefox plugin
On Fri, Nov 13, 2009 at 06:22:06PM +0900, David Cournapeau wrote:
On Thu, Nov 12, 2009 at 12:24 AM, Wolodja Wentland
wentl...@cl.uni-heidelberg.de wrote:
The FHS differentiates between various classes of files and defines
proper location for them. We could define platform dependent
On Fri, Nov 13, 2009 at 21:36 +0900, David Cournapeau wrote:
On Fri, Nov 13, 2009 at 7:38 PM, Wolodja Wentland
wentl...@cl.uni-heidelberg.de wrote:
Could you elaborate on this idea please? Do you mean that megabars
plugins are shipped in a different distribution than megabar itself?
Yes.
On Fri, Nov 13, 2009 at 13:04 +, Floris Bruynooghe wrote:
+1
:-)
But don't expect all package maintainers to suddenly classify their
datafiles properly. Last time this got discussed there was
significant opposition to this, maintainers did not see the point and
didn't want *any* change
On Fri, Nov 13, 2009 at 21:36 +0900, David Cournapeau wrote:
Yes. Imagine that I create a library, which includes a firefox plugin
in python. I need to differentiate between what will end up in firefox
and the rest.
One thing I find noteworthy/horrifying about your *Firefox* plugin
example is
On Nov 13, 2009, at 9:01 AM, Wolodja Wentland wrote:
This would mean that the *default* install should be PEP 370 compliant
or inside a virtualenv and that installing into system paths should be
enabled explicitly.
+1.
___
Distutils-SIG maillist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Floris Bruynooghe wrote:
On Fri, Nov 13, 2009 at 06:22:06PM +0900, David Cournapeau wrote:
On Thu, Nov 12, 2009 at 12:24 AM, Wolodja Wentland
wentl...@cl.uni-heidelberg.de wrote:
The FHS differentiates between various classes of files and defines
On Fri, 13 Nov 2009 15:25:38 -0500, Tres Seaver tsea...@palladion.com
wrote:
* configuration etc
* shared data usr/share/foo/
* readmeusr/share/foo/READMEREADME, TODO, ...
could
be automatically
On Fri, Nov 13, 2009 at 10:04 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
On Fri, Nov 13, 2009 at 06:22:06PM +0900, David Cournapeau wrote:
On Thu, Nov 12, 2009 at 12:24 AM, Wolodja Wentland
wentl...@cl.uni-heidelberg.de wrote:
The FHS differentiates between various classes of
On Wed, Nov 11, 2009 at 4:24 PM, Wolodja Wentland
wentl...@cl.uni-heidelberg.de wrote:
[..]
Proposal
I propose three things:
1. Save installation prefixes for every installed distribution
2. Define standard infixes for typical data file classes
3. Implement an API that is able to
Hi all,
I had a discussion with Tarek on IRC yesterday and would like to bring
some points to your attention and also write down some conclusions/ideas
we had yesterday.
I think that the distutils module has a serious flaw that need to be
addressed before any further work is done on getting PyPi
On Wed, Nov 11, 2009 at 16:24 +0100, Wolodja Wentland wrote:
The installation prefixes could for example be saved within a suitable
file in .egg-info/ which would mandate changes to PEP 376. I could think
of a PREFIX file and the following methods/attribute for e.g. the
Distribution class
I
14 matches
Mail list logo
