If there any way to get Distribution information given the module name
like 'trac.admin.web_ui' in setuptools?
There is a problem to extract information about exact distribution
name and version when module is already imported in application (Trac
I am looking to download the software that lets me connect to MySQL
3.23.52 in Python 220.127.116.11 running on HP-UX 11.00
Could you please help me with information on where I can obtain it?
A reply will be very much appreciated.
I've got a problem using mingw32 (gcc 4.4.0) with distutils for my extension module.
The error message appears in the linking step:
g++: build\temp.win32-2.6\Release\.\cmf\cmf_core_src\lib_cmf_core.a: No such file or directory
Which is puzzling me, since lib_cmf_core.a should be build by --output-lib alongside to _cmf_core.pyd. Compiling with VS2008 works fine.
Christian K. posted the same problem 2 years ago in the thread "[Distutils] errors compiling c++ extensions with swig on windows" (my extension is wrapped by swig also) but never got an answer.
Does anybody know by now how to deal with this problem?
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
At 09:13 AM 1/9/2010 -0600, Brad Allen wrote:
>On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby <pje(a)telecommunity.com> wrote:
> >> Yes, very much. I like 'parcel' better than 'project', partly because
> >> it's not already overload with other contextual meanings.
> > This is just another example of the degree of confusion around terminology
> > here, because "parcel" isn't a substitute for "project": a "project" is
> > something that you would release "parcels" *for*.
>These two terms have yet to be formally adopted, so they can mean what
>we want them to mean.
You miss my point: the usage of "project" you were commenting on was
not in reference to the same thing as your comment. In the context
of the thread, "project" was referring to "thing that has releases"
and "parcel" was being used as a substitute for the existing term
"distribution" or "module distribution".
(And even if it's *me* who's confused here, the point still stands
about the degree of confusion. ;-) )
Anyway, IMO "parcel" works great as a substitute for "distribution"
(as it is a concrete term for a concrete thing) and not so great as a
substitute for "project" (since a project isn't that concrete a thing
and "parcel" therefore seems *too* concrete).
At 10:29 AM 1/7/2010 -0600, Brad Allen wrote:
>On Thu, Jan 7, 2010 at 9:12 AM, John Gabriele <jmg3000(a)gmail.com> wrote:
> > On Thu, Jan 7, 2010 at 9:56 AM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote:
> >> On Thu, Jan 7, 2010 at 3:52 PM, John Gabriele <jmg3000(a)gmail.com> wrote:
> >>> The only inconsistency, I think, is that operating systems like Debian
> >>> refer to their software distributions as "packages" (as in, a packaged
> >>> up piece of software that you can download and install). "Packages" is
> >>> a great name for them -- too bad it's already being used in Python.
> >> I believe that's basically where the confusion comes from.
> > Whoops. Just noticed that the front page of the PyPI says:
> >> "There are currently 8614 packages here."
> > (is that 8614 packages or 8614 distributions?)
8614 *projects*, some of which have one or more *versions*, which in
turn may have one or more source or binary *distributions*. That at
least is the terminology that setuptools and distribute use in their
documentation at the moment.
while toying with the entrypoint system, i repeatedly ran into the need
of having additional metadata prior to importing
In Plugins that only handle certain filetypes/extensions/mimetypes might
profit from the additional metadata (while also defering imports)
The same goes for my library anyvc that needs to know what directories
to check for, however usually the directory checking is a lot faster
than doing the imports (and implementing custom lazy importing is pain).
So i propose supporting to store additional metadata along with the
the current data is stored in the form of a ini file a la:
namea = import [extras]
nameb = import
Which basically translates to the following data entries per entrypoint:
:group: the group of that entrypoint
:name: the name
:import: the default import
:extras: the setuptools extra dependencies
Now i'd like to add custom entries to that,
and i see various ways to store those
* list of json objects includ (strongly prefered by me)
* adding [group:name] sections right after each group section
that encode the additional metadata (see examples)
This would allow basic uses like::
creole = foo.bar:CreoleRenderer [creole]
fnmaps: *.creole *.wiki
Brainfuck = bf:BfLexer
filenames: *.bf *.brainfuck
Additionaly the load method of the Entrypoint class could grow a
optional parameter for alternative imports
That would allow listings like::
subversion = anyvc.subversion [subversion]
mercurial = anyvc.mercurial [mercurial]
workdir_has_paths: .svn/entries .svn/props/
repo_has_paths: format hooks/ db/ conf/ locks/
workdir_has_paths: .hg/requires .hg/store/
repo_has_paths: .hg/requires .hg/store/
Then one could just choose specific imports by passing the new name of
the import to the load function like::
workdir_type = ep.load('workdir')
repo_type = ep.load('repo')
As you can see the above is a pretty rough idea and in need of
The advantage over just having sets of Entrypoints with group, name,
import is that this metadata extension provides a much more pleasant
entry to medium sized feature and removes the need to import for various
metadata checks (in some of my cases, importing entrypoints completely
dominated the execution times)
I also played with the idea of having separate entrypoints for metadata
and modules, but there are many cases where that kind of use seems
unpractical or really just unpleasant to me.
An additional item of interest is having multiple Entrypoints which do
the same thing but, are implemented using different dependencies (and i
want them ordered by some kind of preference/priority).
(but i suppose in case of doubt i could implement those as sort by a
What is currently the preferred way to specify (in your simple
setup.py file) that your distribution depends upon a couple of other
distributions? (All located at the PyPI)
What is expected to be the standard way to do this in the near future?
Also, is it better to specify that your distribution depends upon some
other *distribution*, or some other *packages/modules*?
> FYI. This Distutils-SIG thread is about proposing PEP 345 and impacts PyPI.
> So if there's anything that look suspicious to anyone, please join the
> discussion at Distutils-SIG
In a number of places (Requires-Dist, Requires-Python), comma-separated
lists of version constraints are used. The PEP needs to specify what the
collective constraint means that gets specified.
Most likely, the intended meaning is that the constraints get
and-combined, in which case the example
Requires-Python: 2.5, 2.6
is non-sensical (no Python release meets that constraint). (else,
if it was meant to denote or-combination, then ">1.0, !=1.3.4, <2.0"
would be non-sensical, specifying no constrating at all)
For the Copyright field, I'm not sure what the purpose of it is.
If it is what I think it is (listing attribution), it should probably
be specified as "multiple use".
For Documentation, I think the entire field must be reconsidered.
If it is really meant to be reStructuredText, then the spec should
explain how to do leading spaces/indentation.
For Platform, I fail to see the point of supporting both multiple
use, and comma-separated lists.
For Metadata-Version, I think formally, the only legal value according
to the PEP is 1.2. If 1.0 and 1.1 are also conforming values, the PEP
should elaborate what it means to put a different version number into
At 05:32 PM 1/10/2010 +0100, Lennart Regebro wrote:
>On Sun, Jan 10, 2010 at 16:24, Brad Allen <bradallen137(a)gmail.com> wrote:
> > I had thought 'egg' was just another distribution format, an
> > alternative to tarball, etc. But I have heard people at my local user
> > group use it to mean 'module distribution'.
>Yeah, there is some confusion there. As I understand it, 'Egg' isn't
>even a distribution format,
Right - it's an importable (i.e. addable-to-sys.path) binary
distribution with project release metadata attached. .egg files,
.egg directories, and "flat" installations with associated .egg-info
directories are all "eggs".
(Also, since Python 2.5+ distutils generate .egg-info files, all
distutils-installed module distributions from Python 2.5 on are
>and egg is a package that has extra
Actually, it's a project release with extra information - packages
may or may not be involved, since an egg may contain only a script or
>There is also a distribution format, .egg, but a tarball
>that includes a .egg-info directory is an egg.
Technically, the tarball *contains* an egg, but is not itself an egg,
since it cannot be added to sys.path (at least not without using some
PEP 302 and pkg_resources hooks that nobody has actually used yet, AFAIK).
> A tarball that doesn't,
>but has a setup.py, is not an egg, but may be used to make it one.
Actually, if the tarball was generated by setuptools, then its
contents may also be an egg (since as part of the sdist process, an
.egg-info directory is generated.
At 11:00 AM 1/8/2010 -0600, Brad Allen wrote:
>On Fri, Jan 8, 2010 at 10:29 AM, Lennart Regebro <regebro(a)gmail.com> wrote:
> > Just my 2 cents:
> > - The definitions that Tarek proposed it exactly how I already
> use the words.
> > - I think Python Project Index is a better name than Python Package
> > Index. But Cheese Shop is still better. :)
> > That's all I have to say about it. :-)
>I also liked the 'CheeseShop' name, but what does that leave our
>setup.py thingies being called? Cheeseballs, maybe?
> > Consulting a thesaurus yields one word that nobody has proposed yet:
> > "Parcel". Helpfully, it still starts with "P", so we could rename it the
> > "Python Parcel Index". I have a dim memory hearing this word in a jargon-y
> > context before, but it's certainly considerably more obscure than
> > "distribution", "archive", et cetera.
> > Anybody else like that one?
>Yes, very much. I like 'parcel' better than 'project', partly because
>it's not already overload with other contextual meanings.
This is just another example of the degree of confusion around
terminology here, because "parcel" isn't a substitute for "project":
a "project" is something that you would release "parcels" *for*.