[Distutils] Re: Keywords field in metadata: space separated or comma separated?

[Fred Drake]

On Mon, Nov 18, 2019 at 12:24 PM Paul G  wrote:
> Was anyone on the list involved with the decision to use spaces in the spec? 
> Is there some compelling reason we're missing to make the switch?

distutils was originally conceived and written by Greg Ward at CNRI,
back when Guido led a group there.  Greg was in another group, but
they were active Python users as well.  We (primarily Greg & I) spent
a lot of time discussing distutils and how things should work, but I
don't recall specifically discussing keyword separators.  The whole
keywords thing was pretty geared to our guesses about how an index
would work; actually implementing the first version of PyPI wasn't a
part of Greg's project.

Getting far enough along to build a range of C-based extensions was a
pretty substantial bootstrapping task in the late '90s!

On November 18, 2019 1:07:50 PM UTC, Thomas Kluyver
 wrote:
> The comma-separated format allows keywords containing a space - like 'orbital 
> mechanics' in the example I was investigating (poliastro).

This seems reason enough to stick with the current implementation
approach and forget about space separation.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/U2YH2PXHG6MAUMSXE5EWBDQUI7WQ3JUA/

Re: [Distutils] /etc files

[Fred Drake]

On Wed, Feb 28, 2018 at 4:29 PM, Victor Porton  wrote:
> How to deal with files to be placed into /etc or a similar dir?

setuptools is really an extension of distutils, and for this, the
distutils documentation provides what you need to know:


https://docs.python.org/3/distutils/setupscript.html#installing-additional-files

Good luck!


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

[Fred Drake]

On Wed, May 31, 2017 at 6:48 PM, Paul Moore  wrote:
> What do consumers of the sdist format want to do? I don't actually know,
...
> They also want to publish the sdist to PyPI - so they need to
> name it according to the current convention.

I think we can rule this out for consumers of the sdist; only the
provider cares about this.  If you started from an sdist, you don't
need to publish it to PyPI (though you may want to "publish" to some
repository within your own organization).


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Switch PyPA from IRC to Gitter or similar

[Fred Drake]

On Fri, Jun 10, 2016 at 10:24 AM, Ian Cordasco
 wrote:
> So here's a question: Why are these crucial to you? You've explained
> potential benefits but not why they're crucial to you and should be
> crucial to anyone else.

For people who want an always-on presence, there's also Quassel IRC:

http://quassel-irc.org/

Not sure if that fits Jason's goals, but avoids impacting other users.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] comparison of configuration languages

[Fred Drake]

On May 6, 2016, at 10:59 PM, Nathaniel Smith  wrote:
> Here's that one-stop writeup/comparison of all the major configuration
> languages that I mentioned:
>
> https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f

Thank you for this!  A very nice summary.

On Fri, May 6, 2016 at 11:14 PM, Donald Stufft  wrote:
> While I personally prefer YAML to any of the options on a purely syntax based
> level, when you weigh in all the other considerations for this I think that it
> makes sense to go with TOML for it.

I expect either YAML or TOML would be acceptable, based on this.  I'll
admit that I'd not heard of TOML before, but it warrants consideration
(possibly for some of my projects as well).

I've spent a fair bit of time using YAML with Ansible lately, as well
as some time looking at RAML, and don't find myself worried about the
syntax.  Every oddness I've run across has been handled with an error
when the content couldn't be parsed correctly, rather than unexpected
behavior resulting from misunderstanding how it would be parsed.  It's
entirely possible I just haven't run across the particular problems
Donald has run across, though.

(The embedded Jinja2 in Ansible playbooks is another matter; let's not
make that mistake.)


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Basic Markdown Readme Support

[Fred Drake]

On Tue, May 3, 2016 at 9:29 AM, Jim Fulton  wrote:
> But wait, it's worse. Unlike ReStructuredText, there's no Markdown standard.

We agree that this is a problem, and it's why I don't use Markdown
when tools don't force it.

> In my last job, I had to use a suite of tools (from a single company
> that I won't name but is easy to guess :) )  for which no 2 tools used
> the same dialect of Markdown. :(

Truly a joy.  I'm glad things are better now.  :-)

> Which begs the question, which dialect of Markdown are you suggesting
> we support. :)

If we go with Nick's idea of a client-side solution, we really don't
have to pick just one flavor, though I'd expect GFM would win out for
practical purposes.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Basic Markdown Readme Support

[Fred Drake]

My perspective, for what it's worth, is that while I find Markdown a
horrible pain, there are a lot of people who pick it up before picking
up Python, and tools like GitHub and BitBucket  encourage (and make it
easier to add) README.md to a project. For someone who isn't familiar
with reStructuredText, it's an easier on-ramp.

So while I'm all for encouraging developers to prefer
reStructuredText, I'm in favor of supporting Markdown as a
long_description format. The format for a README file just doesn't
seem such a big deal that alienating potential community members is
worth it.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 376, the INSTALLER file, and system packages

[Fred Drake]

On Fri, Jan 22, 2016 at 1:10 PM, Donald Stufft  wrote:
> Does this sound reasonable to everyone? Do we think it needs a new
> PEP or can we just amend PEP 376 to add this extra bit of information?

Identifying something special like "system" doesn't seem bad, and
conforms (assuming PEP 376 really meant to include "+" at the end of
the regular expression).

If tools find the INSTALLER file and it identifies some other tool,
though, it shouldn't matter if there's a special "system" value.
Debian systems could use "dpkg" or "apt", RPM-based systems could use
"rpm" or "yum", and it sounds like the new pip would be just as happy
to do the right thing.

I don't think a new or updated PEP is needed.  I'm glad to see this
being addressed.  Thanks for all your hard work, Donald!


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Package classifiers - both major and minor Python versions?

[Fred Drake]

On Fri, Jan 22, 2016 at 2:57 AM, Chris Jerdonek
 wrote:
> If "Python 2" really means that all 2.x versions are supported as
> opposed to just some, then that should also be clarified (and
> similarly for "Python 3").

Bingo!  That's the main point, I think.  Because there's no single
reference for what it means to apply any particular classifier, we're
not going to get a lot of mileage from them.

At this point, classifiers are still pretty much recreational.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Package classifiers - both major and minor Python versions?

[Fred Drake]

On Fri, Jan 22, 2016 at 2:06 AM, Marius Gedminas  wrote:
> Are these tools unable to realize that supporting a particular minor
> version implies support for the corresponding major version?

Should supporting 2.7 indicate support for all 2.x releases?

My take is that classifiers should be selected based on intent,
especially given the lack of documentation on how each should be
interpreted.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Requesting PyPI classifiers for Sphinx

[Fred Drake]

On Wed, Nov 26, 2014 at 5:46 AM, Takayuki Shimizukawa
shimizuk...@gmail.com wrote:
 How about this?

 Topic :: Documentation :: Sphinx
 Framework :: Sphinx
 Framework :: Sphinx :: Extension
 Framework :: Sphinx :: Theme

+1


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Requesting PyPI classifiers for Sphinx

[Fred Drake]

On Wed, Nov 26, 2014 at 5:15 PM, Richard Jones rich...@python.org wrote:
 Do you have any idea of the number of existing packages that would fit under
 each of those categories? I'm only asking because I wonder whether we need
 all four right now.

A quick search using the PyPI search box suggests there are a *lot* of
extensions (a couple of hundred?) and even themes (dozens; more than I
expected).  I'm not sure how to search for sphinx-related software
other than extensions or themes with that UI.

I was surprised at just how many relevant packages were listed (a
testament to Sphinx's well-deserved success); I suspect the categories
are justified.  Getting the appropriate package maintainers to be
aware of and apply them is another matter.  That gets back to the
guidance question, which is really separate from this.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Requesting PyPI classifiers for Sphinx

[Fred Drake]

On Wed, Nov 19, 2014 at 10:16 AM, Takayuki Shimizukawa
shimizuk...@gmail.com wrote:
 I'd like to request classifiers for the Sphinx like:

 Topic :: Documentation :: Sphinx
 Topic :: Documentation :: Sphinx :: Extension

I suspect adding Framework :: Sphinx would make more sense for
extensions.  For tools used with Sphinx documentation without being
tied to the Sphinx application itself, Topic :: Documentation ::
Sphinx seems fine.  (I'd imagine an extension would specify both, and
non-extension tools would use only Topic :: Documentation ::
Sphinx.)


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Metadata 2.0: Is there a formal spec for a requirement?

[Fred Drake]

On Tue, Sep 16, 2014 at 8:29 AM, Paul Moore p.f.mo...@gmail.com wrote:
 I've no particular wish to set myself
 up as a competitor to setuptools and distlib :-)

pip install Paul


-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Installing namespace packages with pip inserts strange modules into sys.modules

[Fred Drake]

On Fri, Sep 12, 2014 at 3:34 PM, Thomas Heller thel...@ctypes.org wrote:
 However, when installing it in Python 3.4, this __init__.py file is NOT
 installed. Instead, the 'zope' directory ONLY contains the 'interface'
 subdirectory with all the code.  But a .pth file is installed that does
 the strange things that I mentioned in the original post.

The horrible .pth file in question definitely comes from setuptools.

At Zope Corp., we consistently use zc.buildout to package applications,
which drives setuptools with some long option whose name I forget that
causes the .pth files to be suppressed, and entry-point-based scripts are
generated with the right bits to assemble the sys.path needed for the
application.

For what it's worth.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Removing dependency_links

[Fred Drake]

On Tue, Oct 29, 2013 at 5:45 AM, Marius Gedminas mar...@pov.lt wrote:
 Specifying dependency_links in random packages' setup.py's is a
 nuisance and I would rather it went away.  I always turn it off by
 specifying allow-hosts = *.python.org in buildout.cfg

Some packages indexed on PyPI have downloads elsewhere for various reasons.

You can specify

use-dependency-links = false

to get buildout to ignore dependency_links without limiting the
collection of hosts it
is willing to download from (useful if you use any private repositories).


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PyPI pull request

[Fred Drake]

On Mon, Oct 28, 2013 at 7:29 AM, Donald Stufft don...@stufft.io wrote:
 I thought the name was funny :( You put packages in a Warehouse :3

And Warehouse 13 is where the troublesome packages are stored.  :-)


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Removing dependency_links

[Fred Drake]

On Sun, Oct 27, 2013 at 12:30 AM, Nick Coghlan ncogh...@gmail.com wrote:
 Am I correct in thinking that providing a flag to disable them
 completely will be enough to get ensurepip to behave itself?

There's been a setting for this in buildout for some time, and I don't
build without it.

Your deprecation path sounds reasonable to me.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x

[Fred Drake]

On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver tsea...@palladion.com wrote:
 When in doubt, remove .installed.cfg and re-run buildout after any such
 change.

So the real question is:  Why doesn't bootstrap.py just do this?

I've stumbled on this many times as well; I don't see an advantage to
this not being handled by the bootstrap, because it will surprise us
eventually.

Some of us (include me, apparently) are more easily surprised than others.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PyPI is down

[Fred Drake]

Thanks following up on this!

The server appeared to be flapping from here, and that definitely lasted
longer than 5 minutes (30 or more?).  The flapping could easily have fooled
monitoring, of course.


On Thu, Apr 4, 2013 at 11:54 AM, Brett Cannon br...@python.org wrote:

 Not anymore. Lasted about 5 minutes (at least according the the DOWN/UP
 emails sent to the infrastructure list).

 Monitoring is set up for PyPI so it is known very quickly when it stops
 responding and thus no need to worry about notifying anyone. Noah has done
 a good job. =)


 On Thu, Apr 4, 2013 at 11:48 AM, Andrew Svetlov 
 andrew.svet...@gmail.comwrote:

 Subj

 --
 Thanks,
 Andrew Svetlov
 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 http://mail.python.org/mailman/listinfo/distutils-sig



 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 http://mail.python.org/mailman/listinfo/distutils-sig




-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] Merge catalog-sig and distutils-sig

[Fred Drake]

On Thu, Mar 28, 2013 at 2:22 PM, Donald Stufft don...@stufft.io wrote:
 Is there much point in keeping catalog-sig and distutils-sig separate?

No.

The last time this was brought up, there were objections, but I don't
remember what they were.  I'll let people who think there's a point
worry about that.

 Not sure if there's some official process for requesting it or not, but
 I think we should merge the two lists and just make packaging-sig to
 umbrella the entire packaging topics.

There is the meta-sig, but the description is out-dated:

http://mail.python.org/mailman/listinfo/meta-sig

and the last message in the archives is dated 2011, and sparked no
discussion:

http://mail.python.org/pipermail/meta-sig/2011-June.txt

+1 on merging the lists.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] semver (again)

[Fred Drake]

On Tue, Oct 9, 2012 at 2:24 PM, Daniel Holth dho...@gmail.com wrote:
 How much would it cost to endorse semver?

I endorse it for free.  :-)

Seriously, if a version doesn't conform, I probably don't want to be
using that piece of software, because it's versioning model is overly
complicated.  Integers are cheaper than these discussions; just
increment the right one.  Win: No more dev builds.

Of course, I'm not known for being sympathetic regarding software.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at acm.org
A person who won't read has no advantage over one who can't read.
   --Samuel Langhorne Clemens
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Differences in PEP386 and setuptools

[Fred Drake]

On Thu, Sep 27, 2012 at 1:50 PM, Daniel Holth dho...@gmail.com wrote:
 Ruby gems use http://semver.org/

I don't remember if I was involved in the past discussions (it's possible),
but I'm in favor of using (and requiring) semantic versioning, if only
because we don't have to invent notation or interpretation.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at acm.org
A person who won't read has no advantage over one who can't read.
   --Samuel Langhorne Clemens
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] buildout-versions not showing pinned versions

[Fred Drake]

On Tue, Aug 16, 2011 at 10:14 PM, Chris Withers ch...@simplistix.co.uk wrote:
 *Why* are you pinning in the eggs line?

At Zope, we've had to do this when different processes constructed by a build
had to use different versions of libraries.  buildout-versions aside, it's not
that unusual a case.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
A person who won't read has no advantage over one who can't read.
   --Samuel Langhorne Clemens
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Which buildout to use?

[Fred Drake]

On Tue, Aug 16, 2011 at 7:45 AM, Reinout van Rees rein...@vanrees.org wrote:
 But... sticking to ye olde 1.4.4 seems wrong to me. So I phoned my brother
 Maurits (hi!) who is working with plone: plone is a heavy buildout user, so
 what's the status there? He said plone is basically also still on 1.4.4!

We're mostly using zc.buildout 1.4.4 at Zope Corporation (home of zc.buildout)
as well.  Except where we're using older version (which will get updated
before too much longer).

Buildout 1.5.x introduced features we just haven't needed.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
A person who won't read has no advantage over one who can't read.
   --Samuel Langhorne Clemens
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] DRAFT PEP 396 - module version number

[Fred Drake]

On Wed, Jun 8, 2011 at 6:14 PM, Barry Warsaw ba...@python.org wrote:
 #. For modules which live inside a namespace package, the sub-package
   name SHOULD include the ``__version__`` attribute.  The namespace
   module itself SHOULD NOT include its own ``__version__`` attribute.

I've no idea what you're saying here.  What's a sub-package?

If you're referring to a package like zope.testing, I'd just call that a
package; there's nothing special about that.  I'd expect the __version__,
if it exists, to be present in the file zope/testing/__init__.py.

An namespace package, like zope or zc, should not have a __version__.

Ben Finney wrote:
 I may be fighting against the tide here; but this screams to me that the
 PEP should not be talking at all about “version number” (except to point
 out that they're strings, not numbers). Instead, the term should be
 “version string” throughout.

I'd rather we just say 'version' instead of 'version number' or 'version
string'.  Natural use of natural language is... natural.  A separate
sentence can state simply that versions are expressed as strings.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] DRAFT PEP 396 - module version number

[Fred Drake]

I wrote:
 If you're referring to a package like zope.testing, I'd just call that a
 package; there's nothing special about that.  I'd expect the __version__,
 if it exists, to be present in the file zope/testing/__init__.py.

Ben Finney responded
 Yes, but how to specify that? The ‘__init__.py’ file is a module. What's
 that, then; a package module?

The package zope.testing includes the module zope.testing (implemented in
zope/testing/__init__.py), as well as other modules (zope.testing.cleanup
for example).  The zope.testing module SHOULD contain any appropriate
__version__
attribute.

The only real special cases are namespace packages like zc, zope, and many
others.  Since those are *not* tied to a single distribution, they SHOULD NOT
have __version__ attributes.

(I think we agree on this, but language is tedious, since there are many casual
uses of the term 'package' here, and 'namespace packages' aren't as commonly
known outside particular segments of the community.)


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] DRAFT PEP 396 - module version number

[Fred Drake]

On Tue, Jun 7, 2011 at 11:48 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
    For modules which are also packages, the ``__version__`` attribute
    SHOULD be in the module's namespace.

This suggests to me that there's no need to describe it as a special case.  A
importable directory contains an __init__.py; it's represented as a module at
runtime, just like any other.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] dependencies, pip and non-PyPI-hosted packages

[Fred Drake]

On Fri, Apr 22, 2011 at 12:34 PM, Ernesto Posse epo...@gmail.com wrote:
 PS: since 'requires' and 'provides' are not used in any tool, why are
 they in the official documentation?

We answered the chicken-and-egg problem incorrectly.

Ignore those.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] reservations about pythonv

[Fred Drake]

On Wed, Mar 30, 2011 at 5:08 PM, kiorky kio...@cryptelium.net wrote:
 You have rpath to record search paths for shared libraries at link time.
 This enables you not to set LD_LIBRARY_PATH at runtime.

 Something like cc -Wl,-rpath,/path/to/libdir -L/path/to/libdir -lfoo is what
 you want.

This fails once you want to relocate the built packages, but if you
know what the installed location is going to be, can be incredibly
helpful.


-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] buildout, setuptools, sourceforge problems

[Fred Drake]

On Tue, Mar 29, 2011 at 4:54 PM, P.J. Eby p...@telecommunity.com wrote:
 Update your setuptools to 0.6c12dev-r88975 for the fix.

Egads, Philip!  Do regular version numbers cost more in your neighborhood?


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] easy_install doesn't work when there are multiple Content-Length headers

[Fred Drake]

On Mon, Mar 28, 2011 at 11:08 AM, Hoang Xuan Phu phuneh...@gmail.com wrote:
 Just today I'm using easy_install to install mechanize and it is failing
 with the error ValueError: invalid literal for int() with base 10: '382727,
 382727'. By reading the source code and looking at the headers I see that
 the server is returning 2 Content-Length headers (same value, 382727), which
 is turned into '382727, 382727'. Fixing this should be very easy and I can
 do it then submit a patch. I'm just wondering, as distutils seem to be in a
 forking process, what's the best way to solve this?

This is a problem with httplib, which should be resilient to this
situation.  I've already filed a bug against SourceForge, for
generating an extra (useless) header, but it's only vaguely a bug.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] reservations about pythonv

[Fred Drake]

On Sun, Mar 20, 2011 at 1:48 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
 It's likely that pythonv shoudn't do anything differently, at least
 from the POV of the Python binary. I just wanted to mention a use-case
 for needing LD_LIBRARY_PATH set while running Python.

I'd agree that for the use-cases I've dealt with, it's not clear that
pythonv in particular should be responsible for handling
LD_LIBRARY_PATH; it would at times be convenient, but not essential.
Existing workarounds would still apply, and in some cases would still
be necessary.

There are two primary changes we've wanted to make when the Python
process is started:

- setting environment variables that have to be set for the dynamic
loaded (LD_LIBRARY_PATH is the most common), and

- running as a particular user.

Both of these would require restarting Python to get set up, and
neither is part of getting the basic virtual environment set up.
Getting environment changes made  restarting the interpreter wouldn't
solve both of these, and the run-as-user behavior is definitely
inappropriate for a basic pythonv behavior.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

[Fred Drake]

On Fri, Mar 18, 2011 at 11:09 AM, Jim Fulton j...@zope.com wrote:
 None. Barry's been using Ubuntu too long and has forgotten that Mac OS
 X is Unix. :)

There's also the fact that Python on Mac OS X builds with a .exe
extension; I don't recall it getting installed that way, though.  On a
case-senseless filesystem, distinguishing the python executable from
the Python directory in the sources requires that unfortunate
extension.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] reservations about pythonv

[Fred Drake]

On Wed, Mar 16, 2011 at 10:39 PM, Barry Warsaw ba...@python.org wrote:
 I vaguely recall that while this *should* work, it actually doesn't
 because once the executable has started, $LD_LIBRARY_PATH isn't consulted
 again.

I recall less vaguely, since we've had to deal with this problem more
recently than your Solaris antics.  :-)  The loader consults
LD_LIBRARY_PATH before  main()  is called, initializing it's own
state, and doesn't pick up changes.  This makes a re-exec necessary if
the new value is different from the original (worth checking to avoid
an exec).


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

[Fred Drake]

On Thu, Mar 17, 2011 at 5:33 PM, Carl Meyer c...@oddbird.net wrote:
 Is .cfg generally preferred to .conf for some good reason? I don't
 personally care too much; the former is shorter but the latter looks
 less ugly to me ;-)

That all depends on who you ask; I tend to prefer .conf myself (but
only by a hair).  Jim likely has his own opinion.

 And I kind of dislike the inconsistency in extension; would
 clean.pythonv.cfg be acceptable?

I'd accept that, so long as we pick only one of .conf or .cfg.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposed change to buildout configuration-file handling

[Fred Drake]

2011/3/7 Łukasz Langa luk...@langa.pl:
 If that changes anything, you can expect a 2.4+ compatible version soon (how
 soon depends on when you need it), much like unittest2 ports Python 3.2
 unittest down.

And for Python 2 at least, it can even take it's real name,
configparser.  That won't work for Python 3.1, though.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] distutils extension for dbus service files

[Fred Drake]

Bare distutils characterizes these as data files (*not* package
data).  There's some documentation on that, but I'm not sure that any
sort of transformation is supported for them.

Specialized commands may need to be inserted to handle those cases cleanly.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] disutils2 tests and python 2.5

[Fred Drake]

On Wed, Nov 17, 2010 at 5:02 PM, Éric Araujo mer...@netwok.org wrote:
 I wanted to avoid that.  I’m sure one of the new TestCase methods checks
 for “same items”.

I guess that's fine for the d2 tests.  I should spend a little more
time looking at u2 to determine if it makes sense to start using that
in tests at work (where it adds a dependency, and possibly some
re-knitting of base classes).


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put my tests in my package?

[Fred Drake]

On Wed, Nov 17, 2010 at 10:14 AM, W. Matthew Wilson m...@tplus1.com wrote:
 1.  I would like to put lots of tests/ folders next to the code they
 test, rather than at the top level of the project.  How do I make sure
 the tests folders don't get installed?

I'm sure there's a way to prevent installation in this case, but I
don't know what it is.

 2.  Should I worry about not installing tests?  Should I install them?

Unless you're targeting storage-constrained platform, why shouldn't
you install them?

 3.  Is there any pattern I should follow for organizing my tests
 within my project?

There's a lot of variations here.  Some people prefer your original
arrangement, and others prefer embedding the tests within each package
as you're describing for your new arrangement.  (The later is widely
used in the Zope community.)

Another approach, good if you want to avoid installation of the tests,
is to use a mirror hierarchy for your tests:

pitz/
   pitz/
   cmdline/
   webapp/
   handlers/
   __init__.py
   statichandler.py

   entity/

   tests/
   commandline/
   test_cmdline.py
   webapp/
   test_webapp.py
   handlers/
   test_handlers.py
   test_statichandler.py
   entity/
   test_entity.py

I favor the Zopish approach these days.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setup.py script using python interpreter from previous run

[Fred Drake]

On Tue, Nov 9, 2010 at 5:58 AM, Geoff Bache geoff.ba...@gmail.com wrote:
 Is this a bug?

I think so.

 Or have I missed something in my setup.py? It works of
 course if I remove the generated build directory by hand, but it's
 not so nice to have to remember to do that.

You should be able to remove the build/ directory that was created
where the package is unpacked, and then run the install command with
your python2/bin/python.  The problem is that build and install
are traditionally two distinct steps.  While setup.py takes care of
both for you, it does detect that you switched Python's, so doesn't
re-build for the second.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setup.py script using python interpreter from previous run

[Fred Drake]

On Tue, Nov 9, 2010 at 6:31 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
 Or... keep in that configure file the path to the interpreter and just
 rebuild all scripts in case the interpreter has changed.

+1 to the simple approach.

Given the need to do this, I guess I don't really see the value of
storing scripts in the build tree.  But I suppose someone actually
uses them from there somehow.  (I'd expect getting the imports to work
would be a painful exercise, but I've seen enough tortured processes
that I wouldn't put it past folks.)


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Copying entire directory

[Fred Drake]

On Wed, Oct 6, 2010 at 12:54 PM, Friedrich Romstedt
friedrichromst...@gmail.com wrote:
 It's in my
 opinion always a good idea to try to avoid hard-coding directory
 separators (/), and to use os.path.join() instead.

Distutils specifically wants / rather than the local platform's
separator, and takes care of conversion as needed.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Copying entire directory

[Fred Drake]

On Wed, Oct 6, 2010 at 1:06 PM, Friedrich Romstedt
friedrichromst...@gmail.com wrote:
 Sure, thanks for the correction!  Don't know if glob would need
 platform-specific separators, though?

The glob module does need platform separators.  When used indirectly
via distutils, / is always the right thing, though.  distutils is
required to ensure the transformation is performed before passing
paths through to glob.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] docs/ vs doc/

[Fred Drake]

On Tue, Sep 21, 2010 at 10:20 AM, anatoly techtonik techto...@gmail.com wrote:
 upload_docs command will extract documentation from 'docs/' by
 default. I wouldn't bring this question if it could also process
 'doc/' in cases where 'docs/' are absent. You can specify upload
 directory explicitly, but sometimes you'd really like it to just work.

Of course, we'd have to define what just work means here.  I'd be
fine having to always tell upload_docs where to look, provided I can
do that in the setup.cfg d2 uses.

That said, I don't *mind* if it looks for both docs/ and doc/, or even
care which it looks for first.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] bug related to package name capitalisation

[Fred Drake]

On Thu, Aug 12, 2010 at 11:01 AM, Chris Withers ch...@simplistix.co.uk wrote:
 As such, I'd expect buildout's version pinning to be case agnostic as well.
 What do other people feel about this?

A lot of case-insensitivity is present for dealing with
case-insensitive file systems; when looking at a distribution, the
case of the name often doesn't matter.

For importable names, case *does* matter; Python bothers to verify
case on case-preserving file systems.

I've seen very few cases where case-insensitivity in package names is
tolerated (once, I think).  There's no reason to spread the
case-senseless disease any further.


  -Fred

--
Fred L. Drake, Jr.    fdrake at gmail.com
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] bug related to package name capitalisation

[Fred Drake]

On Thu, Aug 12, 2010 at 5:59 PM, Chris Withers ch...@simplistix.co.uk wrote:
 I guess my point is that, by way of being based on setuptools, buildout
 already *is* case insensitive w.r.t. distribution names and the fact that
 *only* version pinning *is* case sensitive ends up being a bug...

The fix for probably include abandoning setuptools and case-senseless
file systems.


  -Fred

--
Fred L. Drake, Jr.    fdrake at gmail.com
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] zc.buildout: Declare options in a recipe and use it in another recipe

[Fred Drake]

On Tue, Aug 10, 2010 at 10:27 AM, Udo Spallek ud...@gmx.net wrote:
 I try to catch this with the buildout.cfg and recipe attached below. The
 recipe is found, installed and called with part1 right before part2. So
 far so good.

Options initialized by your recipe's constructor will be available to
other recipes.


  -Fred

--
Fred L. Drake, Jr.    fdrake at gmail.com
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] `setup.py register` can't create PyPI account.

[Fred Drake]

On Mon, Jul 12, 2010 at 7:07 AM, Takayuki Shimizukawa
shimizuk...@gmail.com wrote:
 However, the usage of the register command is written on a
 manual (http://docs.python.org/distutils/packageindex.html), and
 many people will meet with the same problem by using the method.

I guess it's been a long time since I've seen that menu!

This does indicate a bug, which should be fixed.  Part of the fix
should include a test for PyPI that an account can be created using
the interface invoked by distutils.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] `setup.py register` can't create PyPI account.

[Fred Drake]

On Sun, Jul 11, 2010 at 4:47 AM, Takayuki Shimizukawa
shimizuk...@gmail.com wrote:
 I wasn't able to make an account in PyPI using `setup.py register`.

The name of the register command is a little confusing.  It's
purpose is *not* to allow you to register yourself with PyPI, but to
register package information with the site.

You need to use the web interface to create your account.  When using
setup.py register, you'll be asked to authenticate using the account
you created via the web.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] buildout 1.5 sometime ever please?

[Fred Drake]

On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER agros...@gmail.com wrote:
 Right now I even cannot get the buildout trunk bin/buildout'ed on
 ubuntu. Does it work for you?

It builds for me (Python 2.6 w/ distribute; haven't tried with
setuptools), but the tests aren't passing because someone added a
dependency on zope.testing, but hasn't fixed the declared
dependencies.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] buildout 1.5 sometime ever please?

[Fred Drake]

On Thu, Jul 8, 2010 at 12:00 PM, Gary Poster gary.pos...@canonical.com wrote:
 Note that dev.py continues to be the supported way to build buildout's trunk, 
 rather than using bootstrap.

I get the same errors using that, with either setuptools or
distribute.  All the errors relate to zope.testing references.

zope.testing is not mentioned in setup.py.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Buildout not working with Bash wrapper for `python'

[Fred Drake]

On Fri, Jun 18, 2010 at 2:20 PM, Arfrever Frehtes Taifersar Arahesis
arfrever@gmail.com wrote:
 Linux supports interpreters being scrips since 2.6.28.

Too recent to be deployed on many production servers, unfortunately.
But progress none-the-less.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
A storm broke loose in my mind.  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] ..\setup.py relative invocation

[Fred Drake]

On Sun, May 9, 2010 at 1:52 PM, Éric Araujo mer...@netwok.org wrote:
 make has a -C option that takes as argument the directory to cd to
 before running. Would something like that be ok?

As long as there's a setup.py, cd'ing to that directory seems better
than requiring more of the end user.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 376 Status

[Fred Drake]

On Thu, Mar 25, 2010 at 6:20 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
 - docutils-0.5.pkg-info/
    METADATA
    RECORD

+1  :-)


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Releasing eggs as .tar.gz with setuptools or zc.buildout

[Fred Drake]

On Wed, Mar 24, 2010 at 12:22 PM, Baiju M mba...@zeomega.com wrote:
 May be this will be useful:
 http://pypi.python.org/pypi/zc.sourcerelease

It sounds to me like Martin's problem isn't getting source releases,
but in deploying them on systems without compilers and other tools.

What we're doing at Zope Corporation is building source releases
(using zc.sourcerelease as Baiju suggested), and then building
packages that the system package management tools can use from those
source releases.  (In our case the packages are RPMs, but it could be
anything.)

But the zc.sourcerelease releases are a good starting point for that
since the dependency packaging and management is handled for you.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Releasing eggs as .tar.gz with setuptools or zc.buildout

[Fred Drake]

On Wed, Mar 24, 2010 at 12:48 PM, Baiju M mba...@zeomega.com wrote:
 Can you give some pointer how you are creating RPMs for
 the binary eggs (eg:- zope.interface ) Any tool available ?

The RPM is built using the normal RPM tools: we write a spec file,
then run rpmbuild in what we think are the normal ways.  Nothing
special is needed.

 These RPMs are for entire buildout or individual eggs ?

For the entire buildout, since they're applications.  We use a
separate package (RPM) with a clean Python (nothing in
site-packages!) that won't be affected by general system updates.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Fwd: The fate of Distutils in Python 2.7

[Fred Drake]

On Mon, Mar 1, 2010 at 2:17 PM, K. Richard Pixley r...@noir.com wrote:
 It's not clear to me that there's much need for new packaging tools in older
 versions.

I've certainly found it useful to use distribute under Python 2.4.
There are still a lot of people using Python 2.4.

I think the general rule for packaging tools is that you want one that
supports all the versions of Python you're using.  Given that there
are good reasons to try again, it's reasonable to support 2.4.

Migrating to newer versions can take a significant transition period
for some applications.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] 70 packages in total use setuptools' extras feature

[Fred Drake]

On Thu, Dec 3, 2009 at 1:05 PM, kiorky kio...@cryptelium.net wrote:
 I know at least one package not in your list: zope.component [1].

Indeed.  Many z3c.* and zope.* packages provide extras that aren't
referenced by other packages directly, but are referenced from
buildout configurations or similar.

It would be interesting to have a good way to judge the uptake for
this feature, but I'm afraid this measure says little beyond they are
used.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] zc.buildout bootstrap errors

[Fred Drake]

On Mon, Nov 2, 2009 at 5:23 PM, Chris Withers ch...@simplistix.co.uk wrote:
 Maybe try and earlier version of bootstrap?
 I idley wonder if this is some side effect of the make-distribute-work work?

This could happen before that; I saw it as soon as Philip started
releasing new versions of setuptools.

I suspect that it's due to buildout trying to use the latest
ez_setup.py or something like that with a fresh build, and that wants
to use the latest setuptools.

I've been using distribute ever since, and have been happy with it.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Alternate static metadata PEP submission...

[Fred Drake]

On Fri, Oct 30, 2009 at 6:24 PM, Chris Withers ch...@simplistix.co.uk wrote:
 I think python setup.py install is so idiomatic that it seems silly to
 break it for the sake of two lines of python.

Idiomatic, yes.  But it's an idiom that developed as a side effect of
the implementation.

This may well have been a reasonable choice at the time it was made
over a decade ago (and yes, I was there, discussing distutils with
Greg Ward during the birthing, so you can probably even lay some of
the blame at my feet).  That would reflect the youth of Python
packaging more than anything else.

 There's also an element of explicit is better than implicit
 in the feel of actually running setup.py...

Running a known implementation isn't explicit?  I worry more about
having to review someone else's ad-hoc setup.py, usually under
deadline pressure, especially given how many variations there are.

Both are explicit; one is less risky.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Alternate static metadata PEP submission...

[Fred Drake]

On Tue, Oct 27, 2009 at 11:26 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
 You can't ban setup.py: although a lot of packages can rely on a purely
 declarative package description, some package won't be able to do so
 (unless your declarative thing ends up being a full language).

Given the variety of special cases that have to be dealt with, we'll
always have to a way to build packages that use Python code for what
we're currently using setup.py for.

For the many packages that don't need that level of flexibility, using
a tool that consumes static metadata is a major win, so long as we
keep in mind that tools need to be able to determine when that static
metadata is sufficient.  That allows the development of tools that can
usefully get things done *and* refuse to run untrusted code
themselves.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Alternate static metadata PEP submission...

[Fred Drake]

On Wed, Oct 28, 2009 at 10:23 AM, Chris Withers ch...@simplistix.co.uk wrote:
 setup()

 ...would get everyone from the static metadata file, while any keyword
 parameters to setup would override the appropriate setting from the static
 metadata file...

I'd rather see the static data in setup.cfg and no setup.py if there's
no need for custom Python code.  There are too many ways to write

from distutils.core import setup
setup()

to make it useful as a way to say the static metadata is sufficient.

That aside, being able to use an empty setup call like that is a
good first step.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

[Fred Drake]

On Wed, Oct 28, 2009 at 10:09 AM, Chris Withers ch...@simplistix.co.uk wrote:
 By is, I'm sure you mean needs to be. Specifying setuptools in
 install_requires is pointless chicken-and-egg'ing. But maybe I mean
 setup_requires thanks to setuptools interesting parameter naming ;-)

You just might.  install_requires is for what's needed at run time,
which is what most of us mean when we refer to install_requires by
name.

 Er? I *only* use buildout, however, I think I may have exempted myself by
 avoiding namespace packages until PEP 382 is done, dusted and in a python
 release.

Your use of buildout is obvious in many contexts, but do realize why I
(and likely others) wondered at your insistence that mentioning
setuptools there was meaningless.  Clarifying this hasn't been cheap
(though valuable, IMO).


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

[Fred Drake]

On Tue, Oct 27, 2009 at 11:35 AM, Chris Withers ch...@simplistix.co.uk wrote:
 I'm talking about *at all*.

If I don't include setuptools in install_requires, then I've no
business expecting it to be available at runtime.  Since our current
approach in the Zope community is to use pkg_resources to support
namespace packages, and we get that via setuptools, it makes sense to
specify that my packages require setuptools.

It's just unfortunate that we're not able to get what we need from the
standard library for all interesting versions of Python.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

[Fred Drake]

On Tue, Oct 27, 2009 at 12:26 PM, Chris Withers ch...@simplistix.co.uk wrote:
 You're ignoring the fact that for the information in install_requires to
 even be parsed, you need to have setuptools present.

install_requires is processed at install time.  At that time, clearly,
setuptools/distribute is present.

That's not necessarily the case at run time.  I see no reason to
expect that having setuptools or distribute on sys.path at install
time would cause it to necessarily be on the path at run time if my
package doesn't provide information that it's needed at run time.

 I'll say it again: it seems pointless specifying a requirement that has to
 be met before any requirement specifications can even be processed...

It doesn't sound to me like you've used buildout nearly as much as easy install.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

[Fred Drake]

On Tue, Oct 20, 2009 at 7:05 AM, kiorky kio...@cryptelium.net wrote:
 buildout, zc.recipe.egg and others recipes flavors do.

These tools don't parse setup.py; they execute setup.py in a
constrained context (possibly a separate process; don't recall
offhand) in order to collect the metadata.

Parsing the setup.py would be insane.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [RFC] PEP 345 and PEP 386 updates

[Fred Drake]

On Tue, Oct 20, 2009 at 7:37 AM, M.-A. Lemburg m...@egenix.com wrote:
 Where's the benefit of renaming the above three fields ?

I don't see any benefit here either; if we want to add fields for
Python package or anything else, new (more explicit) field names can
be added, without ever requiring these to be changed.

As much as having more explicit names would be nice, it's not worth
the disruption caused by deprecation cycles, or the accompanying
confusion.  These sorts of changes have very long uptake, while the
clarity benefit is close to non-existent.

 I'd also remove the Requires- from Requires-Python and
 simply use Python as field name.

+0

 The micro-language should provide a limited number of
 variables to use on the conditions:

 python_version = sys.version
 sys_platform = sys.platform

If we adopt such a micro-language (I'm reserving judgment until I've
had more time to read the relevant PEPs carefully), I'd rather see the
names match what's in the Python runtime more closely, probably only
avoiding the call syntax.

This would make the examples:

  requires: pywin32; if sys.platform == 'win32'
  requires: bar (1.0); if sys.platform == 'win32'
  requires: foo; if platform.machine == 'i386'
  requires: bar; if sys.version == '2.4' or sys.version == '2.5'
  requires: baz; if 'linux' in sys.platform

 The same notation could also be used in setup() keyword
 parameters for the meta-data fields, e.g.

Whatever notation is adopted should be used consistently.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

[Fred Drake]

On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers ch...@simplistix.co.uk wrote:
 As is specifying the setuptools distribution as a requirement when you're
 already using it...

I don't use setuptools at runtime unless something requires it.

Having it available at install time and run time are two different
things, and should remain so.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Alternate static metadata PEP submission...

[Fred Drake]

On Wed, Oct 14, 2009 at 5:59 PM, David Lyon david.l...@preisshare.net wrote:
 ConfigParser is in every python version that I know of.

ConfigParser was first documented in Python 1.5.2, released 30 April 1999.

Some of us remember the releases that came before, but (thankfully)
we're outnumbered.  :-)


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Alternate static metadata PEP submission...

[Fred Drake]

On Wed, Oct 14, 2009 at 11:16 PM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
 I don't think python 1.5 should be considered - I happen to contribute
 to scons, which is a build tool in python, and supports all python
 versions from 1.5.2: the 1.5 requirement is a real downside.

I hope 1.x isn't a target for any of these projects.  At this point,
I'd consider support for Python 2.4 to be quite generous on the part
of the developers.

And yes, I'm still using Python 2.4.  Thankfully I'm not developing or
maintaining anything on Python 2.3.  I would be surprised if there was
widespread interest in adopting new tools in projects using such old
versions; keep in mind that even if something stable is available in 6
months, it'll be a year or more before adoption becomes widespread
anyway.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Python-Dev] Bits-of-Distribute naming

[Fred Drake]

On Fri, Oct 9, 2009 at 12:08 PM, Chris Withers ch...@simplistix.co.uk wrote:
 distutils.entrypoints would seem to be the sensible place.

Why's that?  On the whole, I don't think entry points are specific to
building  bundling, which is what distutils is all about.

Entry points are about packages being able to provide metadata about
how parts of them can be used.  I'd rather see a pkgutil.entrypoint
module with APIs for this.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] Metadata-Version in PKG-INFO

[Fred Drake]

On Sun, Apr 19, 2009 at 6:14 AM, Martin v. Löwis mar...@v.loewis.de wrote:
 However, that wording is specific to the LGPL (and the GPL),
 and does not apply to any other license.

More importantly, it only applies if you specifically include it.

The problem I see is with non-specification; it should be more
difficult to specify imprecisely (by including text as described) than
to specify precisely.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] Metadata-Version in PKG-INFO

[Fred Drake]

2009/4/18 Carlos Tejo Alonso carlos.t...@fundacionctic.org:
 BTW, I asked today a friend who is involved in license issue and she
 explained me that: if the version of a license is not declared in a software
 product, that means that the license applied is the last one.

The last one at the time of licensing or the last one at the time
someone comes back later and asks?

Either way, the answer will change depending on who you ask; there's
not necessarily exactly one answer.

The licensor is responsible for specifying the license; there's no
value in an unspecified version.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] Classifiers for Python versions

[Fred Drake]

On Sat, Oct 18, 2008 at 9:00 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
 With these, packages can indicate that they support 2.x
 (but not 3.x), or that they have been tested/written for
 specific Python releases.

 As a side effect, packages can now expressly state that they
 support Python 3000.

Thanks, Martin!  This is good news.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] Distutils and PyPI : P4-Sprint in D.C.

[Fred Drake]

On Tue, Oct 7, 2008 at 10:35 AM, Tarek Ziadé [EMAIL PROTECTED] wrote:
 We are going to have a P4-sprint (pre-pre-pre-PEP sprint) in D.C.
 during the Plone Conference.

Very cool.

Given the venue, should people expect that they're welcome in person
even if not associated with the Plone conference?

I don't know if I'll be able to steal some time from my family, but
there's a possibility.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] pre-PEP : Synthesis of previous threads, and irc talks + proposals

[Fred Drake]

On Wed, Oct 1, 2008 at 8:10 AM, Tarek Ziadé [EMAIL PROTECTED] wrote:
 8/ the requires-python field is rarely used by people, so unless you
 try the package, you don't know when it is a source
distribution, if it is going to run on various python versions.

What requires-python field?

I don't see this documented for distutils or setuptools.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] wanted: a catalog of setuptools plugins

[Fred Drake]

On Jan 28, 2008, at 9:41 AM, zooko wrote:
 And this morning I just noticed the keywords field in the
 metadata.  Perhaps the setuptools docs could encourage authors of
 setuptools plugins to put the keyword plugin into their keywords?

Another option, for which there's precedent, is to define a classifier  
for the setuptools framework, similar to the classifiers used for the  
various web frameworks.


   -Fred

-- 
Fred Drake   fdrake at acm.org




___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Tiny little zc.buildout documentation bug

[Fred Drake]

On Aug 9, 2007, at 5:10 PM, Jeff Shell wrote:
 The problem is that this first mention of the user-defaults config
 file uses the plural defaults.cfg. The system itself expects the
 singular default.cfg, and the test/example code immediately
 following the above line uses the singular 'default.cfg'.

Fixed in Subversion.  Thanks, Jeff!


   -Fred

-- 
Fred Drake   fdrake at acm.org



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setuptools controversy (was Re: Prototype setuptools-specific PyPI index.)

[Fred Drake]

On 7/23/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
 However, I'm entirely reconciled to it being controversial.  It is in
 fact impossible to have a significant impact on *anything* without
 creating controversy, as anyone involved with the history of Zope
 should be well aware.  ;-)

Our level of expertise in that is certainly substantial.  :-)

 Usually, people think they can get away with making simpler
 versions of Zope because they don't understand the full range of
 requirements which it is intended to meet.  The situation with
 setuptools is much the same, except that sometimes now it's the Zope
 folks making the accusations of too many features, excess complexity,
 evil, etc.  :)

I don't think I made an accusation myself.  My concern is fed by my
belief that setuptools tries to improve on distutils in many different
ways, some of which seem better suited to separate tools.

I've no problem with you disagreeing with me on this.  :-)


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] Prototype setuptools-specific PyPI index.

[Fred Drake]

On 7/22/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
 Setuptools has lots of features that are targeted at different
 audiences.  There are plenty of features targeted at the group you're
 in, don't begrudge the other groups their features.  :)

Actually, I suspect this is a substantial contributor to setuptools
being considered controversial: it encompasses to many different
features.  That certainly keeps me feeling unhappy about depending on
it.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Web-SIG] entry points, etc

[Fred Drake]

On 7/7/07, Ian Bicking [EMAIL PROTECTED] wrote:
 Then there'd also be python module:object, and file
 filename.py:object.  Maybe python  would be the default, I'm not
 sure.

I'd be in favor of not having a default expression type for this, but
to require it to be spelled out every time.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] .egg media type?

[Fred Drake]

On 6/30/05, Ian Bicking [EMAIL PROTECTED] wrote:
 But shouldn't that be application/x-egg+zip ?

Not if it's registered.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Zope Corporation
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] .egg media type? (was: PyPI upload doesn't support eggs?)

[Fred Drake]

On 6/27/05, Ryan Tomayko [EMAIL PROTECTED] wrote:
 The +xml suffix is the only suffixing scheme at IANA and is
 normatively defined in the RFC 3023 XML Media Types [1]. The section
 linked to below contains justification for inventing the suffixing
 scheme, which is almost as interesting as it is amusing. :)

The XML is the first generic data format that has seemed to justify
special treatment (A.14) in certainly humorous, especially given the
context of this discussion.

I'm firmly in the application/egg+zip camp at this point.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Zope Corporation
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig