Is it possible to get the value of install_requires for an arbitrary
package without having to parse setup.py?
I see that --name, --version, --description, --provides, and so on are
available as an argument to setup.py, but --install-requires is missing.
Why?
For example, zc.catalog declares
On 08/04/09 02:53 PM, P.J. Eby wrote:
Something like this should do the trick:
import tempfile, os.path
from setuptools.sandbox import run_setup
def get_requires(setup_dir, empty_tmpdir):
tmpdir = tempfile.mkdtemp(prefix="egginfotmp-")
run_setup(os.path.join(setup_dir,'setup.py'), ['-
On 09-04-27 05:09 PM, Eric Smith wrote:
[Trent]
Or we could have:
RationalVersion(...version bits...)
RationalVersion.from_string(s) # this is a @classmethod
[Tres]
I would prefer keeping the string version of __init__, with the "I'm in
control, dammit" version reserved for the no
New submission from Sridhar Ratnakumar :
Warning messages must be printed to stderr. This allows for a programattic way
to find setup.py metadata.
> pwd
../dap.plugins.sql-0.2.1
> apy setup.py --name 2> /dev/null
'dap.plugins' is declared as a package namespace, but &
On 09-06-08 02:58 AM, Tarek Ziadé wrote:
>
> * Should the PEP specify the encoding of text-files? PEP314 doesn't seem to
specify the encoding of PKG-INFO files, which can cause problems when a field
contains data that isn't ASCII.
The encoding used is utf-8 since 2.6. I think we should rath
On 09-06-08 01:48 PM, Ronald Oussoren wrote:
On 8 Jun, 2009, at 10:36, Sridhar Ratnakumar wrote:
On 09-06-08 02:58 AM, Tarek Ziadé wrote:
>
> * Should the PEP specify the encoding of text-files? PEP314
doesn't seem to specify the encoding of PKG-INFO files, which can
cause prob
On 09-05-15 09:25 AM, P.J. Eby wrote:
My current implementation idea is to unpack the tarball and use the
egg-metadata to figure out what the "egg" name of the tarball should be.
Running "setup.py --name --version" will dump out the name and version,
whether you use distutils or setuptools. If
On 09-06-18 02:05 AM, Tarek Ziadé wrote:
Hi Martin,
We are talking about the "preferred" default archive format in Distutils-SIG.
I was wondering if you could give us some statistics on the various
archives format used at PyPI.
I have a local PyPI mirror .. and it seems there are about 15000
Hi Tarek,
While I was reading this PEP, I noticed that it suggests the '-'
character as separator (between name, version, etc..) .. naturally
introducing '_' *within* names and versions.
'python_ldap-2.5.a_5.egg_info'
This decision looks odd to me, as several package systems I know of use
On Mon, 29 Jun 2009 18:52:01 -0700, P.J. Eby wrote:
The thing is, there is a source distribution of Pyro right there on the
SourceForge website. Why doesn't this grab the .tar.gz file and build
and install it? I thought setuptools did this automatically. Perhaps my
memory is failing me. (It wou
On 6/29/2009 9:33 PM, David Lyon wrote:
On Mon, 29 Jun 2009 19:19:25 -0700, "Sridhar Ratnakumar"
Just throwing out some ideas:
Wouldn't it be better for package authors to register their packages in
PYPI?
It already exists (be it in command line form). See:
http://docs.pytho
On 6/30/2009 5:25 AM, David Lyon wrote:
ok - so on the one hand you are suggesting that people use pypi and
then on the other you are suggesting that activestate will have
its own package repository
ActiveState uses PyPI to get package tarballs in first place. So, for
example, if John uplo
On Thu, 09 Jul 2009 01:22:19 -0700, Tarek Ziadé
wrote:
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumar wrote:
Other than easy_install/pip, there is also PyPM which is being
developed at
ActiveState. PyPM is the Python package manager much like what ppm is
for
ActivePerl.
Great
Here are my comments regarding PEP 376 with respect to PyPM (the Python
package manager being developd at ActiveState)
Multiple versions: I understand that the PEP does not support
installation (thus uninstallation) of multiple versions of the same
package. Should this be explicitly mentioned in
On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziadé
wrote:
get_installed_files(local=False) -> iterator of (path, md5, size)
Will this also return the directories /created/ during the installation?
For example, will it also contain the entry "docutils" .. along with
"docutils/__init__.py"?
I
On Wed, 15 Jul 2009 08:22:03 -0700, David Cournapeau
wrote:
if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is
shipped with it.
As was stated by Debian packagers on the distutils ML, the problem is
that docutils 0.5 breaks packages which work with docutils 0.4 in the
first p
The following file gives the list of all packages in PyPI and their
'install_requires' (or 'requires').
http://files.getdropbox.com/u/87045/x/pypi-dependency.txt
This list does not include (most of the) packages that have external
downloads.
-srid
From my experience in building all the pypi packages, I can confirm that a
significant number of packages (> 10 at least), fail to build[1] because
it cannot read a file (usually LICENSE.txt, version.txt, README.txt in the
sdist root) using __file__.
It is unfortunate that we have this mess
Sorry if I lack the information related to why there is now a fork. But
does this mean that setuptools is becoming a dead project - as in no more
fixes/commits? Or, is there going to be two separate tools - setuptools
and distribute/setuptools2 - that will have ongoing releases?
In anycase,
New submission from Sridhar Ratnakumar :
The following command runs forever. But then, why would it try external
downloads when this package has a tarball on pypi itself?
sridh...@whymac:/tmp/fo > bin/easy_install abstract.jwrotator
Searching for abstract.jwrotator
Reading h
On Fri, 17 Jul 2009 05:41:32 -0700, Tarek Ziadé
wrote:
D- good practices in recipes
+1 on this.
In fact, I'd suggest including a Paste template that will create a sample
project with setup.py in it that makes use of these good practices such as
using ``pkg_resource.resource_string`` to
Both easy_install and pip uses similar method to find download URLs for
packages. They are not very unreliable - see the new issues in Distribute
tracker:
http://bitbucket.org/tarek/distribute/issues/?status=new&reported_by=srid
Hence I suggest that we create a separate project containing
On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby wrote:
The package itself would look something like this:
discovery.resources -- basically pkg_resources under a different name
discovery.sandbox -- basically setuptools.sandbox, less distutils
dependency
discovery.unpack -- setuptools.archive_
On Sun, 19 Jul 2009 12:13:25 -0700, Lennart Regebro
wrote:
2009/7/19 P.J. Eby :
I'm actually kind of hoping that if I make Discovery nice enough,
somebody
else will refactor setuptools to use it. ;-) (Or just replace
setuptools
with something better.)
We hope that too. But we don't th
On Sun, 19 Jul 2009 13:08:01 -0700, P.J. Eby wrote:
At 12:50 PM 7/19/2009 -0700, Sridhar Ratnakumar wrote:
If it was me - I'd certainly do it and that wouldn't jeopardize the
potential fun involved.
Already, just this bit where strangers on the internet discuss how I
should spen
On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby wrote:
discovery.resources -- basically pkg_resources under a different name
It may also be worth adding support for parsing the files under .egg-info
- for instance, those 'extras' in requires.txt. Currently, even pip
hardcodes the parsing of
On Mon, 20 Jul 2009 17:20:44 -0700, P.J. Eby wrote:
At 01:26 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote:
On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby
wrote:
discovery.resources -- basically pkg_resources under a different name
It may also be worth adding support for parsing the files
New submission from Sridhar Ratnakumar :
On Mon, 20 Jul 2009 17:20:44 -0700, P.J. Eby wrote:
At 01:26 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote:
On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby wrote:
discovery.resources -- basically pkg_resources under a different name
It may also be worth
On Mon, 20 Jul 2009 19:46:49 -0700, P.J. Eby wrote:
At 05:39 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote:
I've already looked into that before (in pkg_resources.py) -
unfortunately, this does not return all of requires.txt (as Python dict,
that is), but only *what* you specify in the &#
xt is that file alone.
Note: requires.txt is extracted and stored elsewhere, so I cannot rely in
it being inside .egg-info/ directory in order to parse it.
-srid
On Tue, 21 Jul 2009 17:07:45 -0700, Sridhar Ratnakumar
wrote:
On Mon, 20 Jul 2009 19:46:49 -0700, P.J. Eby
wrote:
At 05:
On Tue, 21 Jul 2009 18:04:00 -0700, P.J. Eby wrote:
Is there anyway to get access to this parsed _dep_map without having a
reference to the .egg-info directory? After all, everything needed to
parse requires.txt is that file alone.
Note: requires.txt is extracted and stored elsewhere, so I can
On Tue, 21 Jul 2009 21:23:00 -0700, P.J. Eby wrote:
If I were trying to do what you're doing, I'd just run a bdist_egg on
the package and inspect it via the API. Or, alternately, I'd run the
egg_info command with an explicit target directory, then load it via the
regular API. (By "regul
On Wed, 22 Jul 2009 12:14:11 -0700, P.J. Eby wrote:
t 12:08 PM 7/22/2009 -0700, Sridhar Ratnakumar wrote:
On Tue, 21 Jul 2009 21:23:00 -0700, P.J. Eby
wrote:
If I were trying to do what you're doing, I'd just run a bdist_egg on
the package and inspect it via the API. Or, altern
On Tue, 28 Jul 2009 12:26:52 -0700, P.J. Eby wrote:
At 03:04 PM 7/28/2009 -0400, Matthew Wilson wrote:
I have a package that depends on the multiprocessing package, which
got added to the standard library as of 2.6.
So, for only those people using python versions before 2.6, I want to
require
On Tue, 28 Jul 2009 13:00:44 -0700, P.J. Eby wrote:
[1] One way to implement conditional requirements is to make use of
Requirement.extras. If setuptools/distribute supports builtin extras -
such as Py26, Py27, Py30 and so forth .. even Py3x to cover all 3.x
versions - then one can have a [ It
What if I already have setuptools installed in the Python installation?
sridh...@double:/tmp/tarek1$ apy bootstrap.py
Downloading http://nightly.ziade.org/distribute-0.6-py2.6.egg
bootstrap.py:42: UserWarning: Module pkg_resources was already imported
from /tmp/tmpCH7Pdb/distribute-0.6-py2.6.eg
Upon using a virtualenv:
$ virtualenv --no-site-packages env1
$ rm -rf env1/lib/python2.6/site-packages/* # remove previously installed
setuptools
$ env1/bin/python bootstrap.py
Downloading http://nightly.ziade.org/distribute-0.6-py2.6.egg
Traceback (most recent call last):
File "bootstrap.p
On Tue, 04 Aug 2009 13:59:12 -0700, Tarek Ziadé
wrote:
2009/8/4 Sridhar Ratnakumar :
What if I already have setuptools installed in the Python installation?
besides the warnings, it should be OK
You can also install distribute over your setuptools by running
bootstraping.py
$ wget http
On Tue, 04 Aug 2009 14:04:21 -0700, Tarek Ziadé
wrote:
$ virtualenv --no-site-packages env1
$ rm -rf env1/lib/python2.6/site-packages/* # remove previously
installed
setuptools
$ env1/bin/python bootstrap.py
Downloading http://nightly.ziade.org/distribute-0.6-py2.6.egg
Traceback (most rece
On Sat, 08 Aug 2009 17:36:43 -0700, Tarek Ziadé
wrote:
0.7
The plan is to start the refactoring:
- py3k support
- split the code in several distributions
- think about new features / behaviors, we need
And 0.7 will have different package namespace (thus not conflicting with
an existi
For applications needing user config files at a new location (not sure
about /dbus-1/services), what I currently find suitable is this:
1. Store the default config files at myapp.module.conf namespace (==
site-packages/myapp/module/conf/foo.conf,bar/baz.conf,etc..)
2. When the application i
I am glad that you have started thinking about the module split.
1) Why are the distributions named in CamelCase? Why not
'distribute.resources' instead of 'DistributeResources' (like, for
instance, zope.interface instead of ZopeInterface).
2) In your proposal below, version comparison is p
On Tue, 11 Aug 2009 17:44:01 -0700, Tarek Ziadé
wrote:
2009/8/12 Sridhar Ratnakumar :
I am glad that you have started thinking about the module split.
1) Why are the distributions named in CamelCase? Why not
'distribute.resources' instead of 'DistributeResources' (
I have a setup.py like this:
[...]
extras_require = {'foo': 'pkginfo'},
[...]
entry_points = {'console_scripts': [
'bar=myapp.bar:main',
'foo=myapp.foo:main [foo]',
]}
[...]
When I do a 'python setup.py install', the package 'pkginfo' is *not*
installed as expected.
On Mon, 17 Aug 2009 17:22:51 -0700, David Lyon
wrote:
[setup]
name: foo
version: 1.0
author: tarek
long_description: some
long description
here
More often developers may want to assign the contents of README.txt to the
`long_description` field. I have seen setup.py's that simply do:
On Fri, 21 Aug 2009 08:15:47 -0700, David Laban wrote:
2. When the application is first run, check for ~/.local (or APPDATA on
Windows) - and if user config directory-or-files is not present, copy
them
from the namespace location to ~/.local.
The app is only ever run by dbus finding the ser
On Fri, 21 Aug 2009 08:05:47 -0700, Martin v. Löwis
wrote:
It might also be useful to have a
distutils command that generates a pypi-like page, so that people can
preview the rendered description.
I often think: why not integrate Sphinx with PyPI's web page generation?
Perhaps a sphinx ex
On Fri, 11 Sep 2009 18:57:28 -0700, P.J. Eby wrote:
At 02:50 AM 9/12/2009 +0200, Tarek Ziadé wrote:
it means that we can even provide an XML-RPC service at PyPI so people
can query the metadata for their platform with zero download and zero
third-party
code execution.
Ah, now that does sound r
On Mon, 14 Sep 2009 07:13:55 -0700, Glyph Lefkowitz
wrote:
So you can for example define a list of dependencies that changes wether
> you are under windows or linux, etc..
OK. I've never had that situation. I'm sure someone has, but it
doesn't see common.
Twisted actually has this. On Wi
On Tue, 15 Sep 2009 02:00:41 -0700, Tarek Ziadé
wrote:
[only_windows]
condition: sys_platform == 'win32'
requires: pywin32
I am ambivalent about using sys.platform. How do I specify Linux?
>>> sys.platform
'linux2'
"linux2"? What are the possible values for `sys.platform`? Is it eve
up.cfg (or a new setup.cfg.in)
is unneeded if the requirements are small.
Just reproducing an related discussion from another thread:
On Tue, 15 Sep 2009 14:12:46 -0700, P.J. Eby wrote:
At 01:46 PM 9/15/2009 -0700, Sridhar Ratnakumar wrote:
install_requires = ['lxml', 'm
On Thu, 17 Sep 2009 07:05:46 -0700, Tarek Ziadé
wrote:
On Thu, Sep 17, 2009 at 3:53 PM, P.J. Eby wrote:
At 12:41 PM 9/17/2009 +0200, Tarek Ziadé wrote:
Also, if I understand clearly the idea, I find it rather cryptic to
add conditions to each dependency
like what Sridhar has shown.
That
On Tue, 15 Sep 2009 17:42:24 -0700, wrote:
What use cases do we have? There's the one described above, which lots
of people have been talking about. I think there's another one related
to target Python version - eg, on Python 2.3, depend on simplejson, but
on Python 2.6, don't. What els
On Wed, 30 Sep 2009 12:26:15 -0700, wrote:
I agree with Tarek that the system dependency handling is not something
that should be dealt with in the python package metadata. The best
thing that can be hoped for is that packages which rely on a specific
version of a system dependency will t
On Wed, 30 Sep 2009 13:58:56 -0700, Ian Bicking
wrote:
The other option could be to enable support for static linking so as to
make the egg a reasonably self-sufficient binary (eg: lxml's --static
flag to setup.py)
Just to throw more in the mix -- this option is totally ad hoc in lxml,
w
On Sat, 03 Oct 2009 14:17:50 -0700, Ned Deily wrote:
On what other platforms is this likely to be a problem? Windows *?
Linuxes? If that can be identified, if necessary the distributors of
Python installers can be informed so they can inform their users (note,
that python.org is itself a dist
On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé
wrote:
The other way would be to use Distribute instead of Setuptools for
what the packaging system is calling "setuptools". That's pretty
much what is happening in Gentoo (arch) and UHU-Linux (dev),
right now
Interesting. Gentoo uses distribu
On Mon, 05 Oct 2009 11:21:28 -0700, P.J. Eby wrote:
And there's nothing all that special about setuptools' subclassing of
build_ext; in fact, if you look back in the archives here, other people
have done equivalent subclassing to support dynamic library building. I
haven't checked their c
On Tue, 06 Oct 2009 10:25:04 -0700, kiorky wrote:
"""
The fork was started by Philip Jenvey at
http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by
Florian
Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/
"""
[1] - http://pypi.python.org/pypi/virtuale
:
- ActivePython26.chm: An MS compiled help collection of the full
ActivePython documentation set. Linux users of applications such as
xCHM might find this useful. This package is installed by default on
Windows.
Extra bits are available from:
http://downloads.activestate.com/ActiveP
On Fri, 09 Oct 2009 04:03:52 -0700, Chris Withers
wrote:
Sridhar Ratnakumar wrote:
This release includes a new packaging tool by activestate called Python
Package Manager (PyPM).
Is PyPM available separately?
No, PyPM comes only with ActivePython (just like PPM does with ActivePerl
On Wed, 21 Oct 2009 16:48:41 +0530, David Lyon
wrote:
My original point was only that 'win32' constant from the stdlib sys
module
is an
inaccurate constant to describe windows now. The stdlib platform module
uses
'Windows' and that seems better.
+1
I suggest to first have a standard libr
New submission from Sridhar Ratnakumar :
> easy_install TracAddHeadersPlugin
Searching for TracAddHeadersPlugin
Reading http://pypi.python.org/simple/TracAddHeadersPlugin/
Reading http://www.trac-hacks.org/wiki/AddHeadersPlugin
No local packages or download links found for TracAddHeadersPlu
Hi,
While reading the PEP I noticed that there seems to be no straightforward
to specify the package release versions.
>>> egginfo_dirname('python-ldap', '2.3.10')
'python_ldap-2.3.10.egg-info'
Consider the following PyPM package file name:
python-ldap-2.3.10_linux-x86_2.6_2.pypm
Her
On Thu, 05 Nov 2009 13:03:45 -0800, Tarek Ziadé
wrote:
If I understand correctly, ActiveState has its own releases of
python-ldap repackaged in pypm files,
and has several releases per python-ldap versions.
Correct. Much like what Linux distributions (like debian) do.
So, why it doesn't h
On Thu, 05 Nov 2009 14:14:19 -0800, Tarek Ziadé
wrote:
I actually now think that storing the release number inside the
.egg-info/
directory may be a better idea. Like:
$ cat python_ldap-2.3.10.egg-info/pypm.txt
release: 2
$
What do you think?
In that case, an arbitrary file that gets ins
On Thu, 05 Nov 2009 14:50:58 -0800, Lennart Regebro
wrote:
I personally find it more convenient to install binaries than from
source.
Why?
1. Not having to deal build errors (due to missing libs or corrupt lib
installations)
2. Not having to have a compiler suite installed (VS, xcode)
On Sat, 07 Nov 2009 07:37:37 -0800, Tarek Ziadé
wrote:
The solution for a better PyPI:
- more checks, more restrictions
- every package maintainer uploading something to PyPI
should have a certain attitude that PyPI is a public
resource where the content should met certain
quality c
On Mon, 09 Nov 2009 07:48:15 -0800, Piotr Ozarowski
wrote:
[Sridhar Ratnakumar, 2009-11-05]
On Thu, 05 Nov 2009 13:03:45 -0800, Tarek Ziadé
wrote:
If I understand correctly, ActiveState has its own releases of
python-ldap repackaged in pypm files,
and has several releases per python-ldap
In line with this discussion, I found a document that details the aspects
of CPAN that can be used for writing packaging systems in other languages.
The author says: over the years people from at least Python, Ruby, and
Java communities have approached me or other core CPAN people to ask
ba
On Sun, 22 Nov 2009 14:52:11 -0800, Tarek Ziadé
wrote:
Hello
As suggested in Catalog-SIG by some people, I would like to propose
the addition of three more fields for 1.2:
"Repository-URL"
A string containing the URL for the package's repository.
Example:
http://svn.python.org/
I thought this list might be of interest to the people here.
Surprisingly not many packages rely on (not declare) setuptools'
"extras" feature [bit.ly/setuptools-extras].
http://paste.pocoo.org/raw/154703/
-srid
___
Distutils-SIG maillist - Distu
On 12/3/2009 10:16 AM, kiorky wrote:
Attila Oláh a écrit :
> It does have a few extras (zcml being the most notable one probably),
> but I don't think it depends on any extras. Other packages may,
> however, depend on zope.component [zcml].
There are many, and as i say, and i know many other
On 12/4/2009 2:43 AM, denis wrote:
Folks,
in setuptools-0.6c11-py2.6.egg/setuptools/package_index.py lines 468-475
if dist is None:
...
return dist.clone(...)
=> of course
AttributeError: 'NoneType' object has no attribute 'clone'
Fixed in setuptools trunk - http://bugs.python.org/setuptoo
On 12/22/2009 10:15 AM, Lennart Regebro wrote:
> Another point that I really like about the service is that the distribution
> pages provide links to many other related services that are run by other
> volunteers. Take for
examplehttp://search.cpan.org/dist/PAR-Repository-Client/
> There is
On 12/23/2009 12:18 PM, "Martin v. Löwis" wrote:
One solution I can think of is this: make PyPI only do the job of PAUSE
> as it does for CPAN; and implement a CPAN like simple directory
> structure to store packages; make PyPI use that as the package data
> store
I don't know what PAUSE is,
On 12/23/2009 1:19 PM, Sridhar Ratnakumar wrote:
What /packages/source/ lacks is:
1/ Missing packages (eg: Twisted is not there); which is why
easy_install/pip had to resolve to scrapping project webpages for
guessing download links. In CPAN, almost all module authors upload their
sources via
On 12/23/2009 1:33 PM, Lennart Regebro wrote:
On Wed, Dec 23, 2009 at 20:24, Sridhar Ratnakumar
wrote:
The reason why PyPI does not have such third-party services - I think - is
that it lacks the CPAN like simple directory structure that can be easily
mirrored using ftp/rsync, to wit:
Nah
On 12/23/2009 2:32 PM, Tarek Ziadé wrote:
On Wed, Dec 23, 2009 at 11:20 PM, Glyph Lefkowitz
wrote:
>
> On Dec 23, 2009, at 4:33 PM, Lennart Regebro wrote:
>
> 1/ Missing packages (eg: Twisted is not there)
>
> The Twisted guys do not upload their packages to PyPI. I think that's
> a mistak
On 12/24/2009 12:33 AM, "Martin v. Löwis" wrote:
1/ Missing packages (eg: Twisted is not there); which is why
easy_install/pip had to resolve to scrapping project webpages for
guessing download links. In CPAN, almost all module authors upload their
sources via PAUSE.
How do you propose to chang
On 12/23/2009 10:42 PM, Lennart Regebro wrote:
On Wed, Dec 23, 2009 at 23:28, Sridhar Ratnakumar
wrote:
I suggested PyPI to disallow mere project listings (without sources) and
require sources to be stored in the server. One way to achieve this is
requiring package authors to use the `sdist
On 12/24/2009 3:00 AM, "Martin v. Löwis" wrote:
Some reasons to have PyPI host packages have already been mentioned in
> this thread: it makes mirroring easier, and it makes it easier for
> individuals to build new services (web sites primarily) that present new
> interfaces to the Python pack
Greetings Lennart,
On 12/24/2009 10:27 PM, Lennart Regebro wrote:
On Fri, Dec 25, 2009 at 05:39, Sridhar Ratnakumar
wrote:
Is it because of this benefit to package authors that we are withholding the
implementation of a simple archive that would: 1) simplify the tools to no
rely on adhoc web
On 12/25/2009 1:09 AM, Lennart Regebro wrote:
Why not? Do you conceive of any reason apart from CPAN-like archives that
would help in proliferation of mirror sites and third-party sites?
>
The point is that we *have* a CPAN like archive.
I am amazed at the amount of denial in this discussion,
On 12/30/2009 10:57 AM, sstein...@gmail.com wrote:
On Dec 30, 2009, at 1:48 PM, Sebastien Douche wrote:
> On Sun, Dec 27, 2009 at 11:47, Lennart Regebro wrote:
>
>> Out of a total of 8522 packages on PyPI, there are 203 packages (2.4%)
>> whose latest release does not provide either a pack
On 1/6/2010 8:23 AM, John Gabriele wrote:
On Wed, Jan 6, 2010 at 11:07 AM, Carl Meyer wrote:
>
> {snip} Following the principle of least surprise I would assume
> they would be requires_dist, provides_dist, etc, and would take lists of
> strings, in the same format as in the PEP (name follow
I originally posted this in Stackoverflow:
http://stackoverflow.com/questions/2150887
Here's my buildout.cfg:
[buildout]
parts = ... pyrtm ...
develop = . parts/pyrtm
eggs = pyrtm
[pyrtm]
recipe = mercurialrecipe
repository = http://bitbucket.org/srid/pyrtm
...
On 1/28/2010 2:57 PM, Jonathan Ballet wrote:
Hello,
Le Thu, 28 Jan 2010 11:32:33 -0800, Sridhar Ratnakumar
a écrit :
> The above buildout.cfg does none of the above. How do I make it work as
> intended?
For this particular usage, I would either:
* Clone the repository by mysel
On 1/28/2010 5:47 PM, Sridhar Ratnakumar wrote:
* Use mr.developer [1] to automate this. I didn't find it very useful,
though,
but this is closer to what you like to do using mercurialrecipe,
despite
mr.developer looks more active and I know several developers which
are using
i
On 2010-02-02, at 1:38 PM, Carl Meyer wrote:
>> Question 2: I thought you could only have one index. So installing
>> something extra from pypi seems out. How do people handle that?
>
> I use pip (and pip requirements files) for installation, and pip has
> both the -i/--index-url option (for r
On 2010-02-05, at 8:13 AM, Tarek Ziadé wrote:
> Hi,
>
> The part that still requires some work is how to handle files prefixes
> in the RECORD file.
>
> Last time we said that we could benefit of having a PREFIXES file.
> Then Wolojda started to work on a much more complete solution to track
>
On 2010-02-05, at 4:57 PM, P.J. Eby wrote:
> At 04:49 PM 2/5/2010 -0800, Sridhar Ratnakumar wrote:
>> Do we have a real-world example for installing uninstallable data files
>> outside sys.prefix?
>
> Scripts aren't always in sys.prefix,
Scripts *usually* go to sys
Ah, very nice!
This was one of the things I wanted to discuss in the sprints. I've been
mentioning this idea internally as well. Having documentation standards would
ultimately benefit the user who could thus have a central place on his computer
to browse documentation for installed Python pack
On 2010-03-01, at 8:44 AM, Sridhar Ratnakumar wrote:
> Is the documentation directory expected to contain files in certain format -
> for example, with a file describing the Table-of-Contents (toc.xml) that
> would then be used to render MSDN like doc tree?
.. and/or make a single-
Tarek,
For some background on this, see
http://bitbucket.org/srid/modern-package-template/issue/9/distribute_setup-should-not-be-used#comment-139503
The intent behind calling distribute_setup.use_setuptools (and
ez_setup.use_setuptools) is that if the user does not have setuptools
installed,
f it is found, and install distribute
only if neither setuptools nor distribute is already installed.
-srid
On 2010-03-15, at 11:18 AM, Sridhar Ratnakumar wrote:
> Tarek,
>
> For some background on this, see
> http://bitbucket.org/srid/modern-package-template/issue/9/distribu
On 2010-03-19, at 10:59 AM, John Griessen wrote:
> How do you best use buildout to
> "simply use a system Python without site-packages at all"?
What I do, as a workaround till buildout officially supports it, is to do this
every time I run buildout:
$ mv /site-packages /site-package
My package's PKG-INFO defaults to 1.0 metadata version. I tried searching
http://docs.python.org/distutils/ to know how to specify 1.2 as the metadata
version (so I can include Classifiers[1], maintainer* fields in it), but
couldn't find any. Does anyone know? Shouldn't this be documented in
ht
On 2010-03-19, at 2:27 PM, Tarek Ziadé wrote:
> On Fri, Mar 19, 2010 at 5:22 PM, Tarek Ziadé wrote:
> [..]
>>
>> You can't do it, distutils will automatically set 1.0 or 1.1 depending
>> on the options you have used. (and not 1.2)
>
> Re-reading the current distutils (1) code, I realize that i
On 2010-03-19, at 2:51 PM, Tarek Ziadé wrote:
> On Fri, Mar 19, 2010 at 5:35 PM, Sridhar Ratnakumar
> wrote:
>> [..]
> If Tres is reading this, I had to do the following hack as
>> a workaroud:
>> from pkginfo import Distribution
>>
>> class PkgI
1 - 100 of 129 matches
Mail list logo
