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

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

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

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

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

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

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

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

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

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

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

'. 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] wanted: a catalog of setuptools plugins

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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.

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

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

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

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.

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

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

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

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

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

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

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

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,

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

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).

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

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

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

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.

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

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

Re: [Distutils] zc.buildout bootstrap errors

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

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

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

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

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

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

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

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

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

Re: [Distutils] PEP 376 Status

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Distutils] docs/ vs doc/

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,

Re: [Distutils] Copying entire directory

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

Re: [Distutils] Copying entire directory

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

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

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

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

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

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

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

Re: [Distutils] disutils2 tests and python 2.5

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

Re: [Distutils] distutils extension for dbus service files

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.   

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

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

Re: [Distutils] reservations about pythonv

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

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

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

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

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

Re: [Distutils] reservations about pythonv

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

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

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

Re: [Distutils] buildout, setuptools, sourceforge problems

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. 

Re: [Distutils] reservations about pythonv

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

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

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

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

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

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

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

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

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’

Re: [Distutils] Which buildout to use?

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

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

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.

Re: [Distutils] Differences in PEP386 and setuptools

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

Re: [Distutils] semver (again)

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.

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

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

Re: [Distutils] PyPI is down

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

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

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

Re: [Distutils] Removing dependency_links

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

Re: [Distutils] PyPI pull request

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.

Re: [Distutils] Removing dependency_links

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

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

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

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

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

Re: [Distutils] Requesting PyPI classifiers for Sphinx

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.

Re: [Distutils] Requesting PyPI classifiers for Sphinx

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

Re: [Distutils] Requesting PyPI classifiers for Sphinx

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

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

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,

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

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

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

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

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

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

Re: [Distutils] Basic Markdown Readme Support

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

Re: [Distutils] Basic Markdown Readme Support

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

Re: [Distutils] comparison of configuration languages

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

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

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

Re: [Distutils] /etc files

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:

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

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