Typical zc.buildout development installs zope.testing to run the tests.
Typical zope.testing development uses zc.buildout.
As you see, porting this to Python 3 gets well... tricky. ;)
So the question (mostly to Jim, I guess) is if there is a way to
easily run the tests for either zope.* or zc.buildout without using
the zope testrunner et al?
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
I'd like to do something like this:
http://python.pastebin.com/m283c0376
Basically, I'm invoking the easy_install command from a script. Where I
specify a number ofn arguments to the --find-links option, some of which
will be web-servers and at least one will be a local filesystem path, or
possibly a network path un UNC format.
It seems to work just fine when I do not provide a --find-links option
(in this case it just picks up the defaults from distutils.cfg), when I
use the option all I get is:
Traceback (most recent call last):
File
"D:\workspace\pythonscripts_trunk\javapy_egg\Scripts\test_javapy.py",
line 20, in ?
result = pyproxy.requireEgg( eggspec , True, hosts )
File
"d:\workspace\pythonscripts_trunk\javapy_egg\src\calyon\javapy\pyproxy.p
y", line 141, in requireEgg
pkg_resources.require(eggname)
File
"d:\python24\lib\site-packages\setuptools-0.6c9-py2.4.egg\pkg_resources.
py", line 626, in require
needed = self.resolve(parse_requirements(requirements))
File
"d:\python24\lib\site-packages\setuptools-0.6c9-py2.4.egg\pkg_resources.
py", line 524, in resolve
raise DistributionNotFound(req) # XXX put more info here
pkg_resources.DistributionNotFound: myproject==trunk-99
Can somebody confirm the correct way to do this? For example do I use
Windows or UNIX slashes? What character must be used to seperate
multiple URLs?
I'm using setuptools 0.6c9 on Windows32
Thansk
This email does not create a legal relationship between any member of the
Crédit Agricole group and the recipient or constitute investment advice.
The content of this email should not be copied or disclosed (in whole or
part) to any other person. It may contain information which is
confidential, privileged or otherwise protected from disclosure. If you
are not the intended recipient, you should notify us and delete it from
your system. Emails may be monitored, are not secure and may be amended,
destroyed or contain viruses and in communicating with us such conditions
are accepted. Any content which does not relate to business matters is not
endorsed by us.
Calyon is authorised by the Comité des Etablissements de Crédit et des
Entreprises d'Investissement (CECEI) and supervised by the Commission Bancaire
in France and subject to limited regulation by the Financial Services Authority.
Details about the extent of our regulation by the Financial Services Authority
are available from us on request. Calyon is incorporated in France with limited
liability and registered in England & Wales. Registration number: FC008194.
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.
Hi all,
I've run into a situation where I need to have translations using
L10nAppDistribution and we need to also have a special command class.
What I'm finding is that I can have one or the other but not both.
Does anyone know how to be able to use both distclass and cmdclass at
the same time?
Regards,
Gerry Reno
New submission from Skip Montanaro <skip(a)pobox.com>:
This is more a reference submission than anything else. I submitted a patch for
pyjamas to remove its installer's hard-coding of /usr/share. In my opinion the
root for all installed files should be whatever --prefix is (whether explicit
or implicit).
The pyjamas ticket is <http://code.google.com/p/pyjamas/issues/detail?id=141>.
Please have a look at it and add a comment if you so desire.
Skip
----------
messages: 251
nosy: skip.montanaro
priority: feature
status: unread
title: setuptools & pyjamas
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue63>
_______________________________________________
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm doing most of my development these days with Python 2.6, and would
like to get a deprecation-warning-free version of zc.buildout released
if possible for the projects which use buildout.
I would be glad to make the release myself, if desired: just bless me
with the PyPI stick and let me know. ;)
Thanks!
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver(a)palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJuQRR+gerLs4ltQ4RAg7cAJ9E6B99dOw1oWWK2lP4Dmk6YdO+BgCfdKAu
ky5VUwFfP6cwqFziwwxoZBE=
=5CBo
-----END PGP SIGNATURE-----
Hello, guys,
I have fixed distutils (and setuptools remains working) with the attached
patch. Now, RPMs will be built according to the Fedora Package Naming
Guidelines:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Non-
Numeric_Version_in_Release
which I understand to be the most useful reference in terms of naming pre-
release packages. This should work correctly in at least:
- Fedora
- RHEL
- SUSE
I urge you patch your python 2.4s and 2.5s and 2.6s and push this update to
distributions. I have done that myself at my own repository.
Now we can enjoy one more reason to build RPMs (and eggs! ... according to my
workbench at http://yum.rudd-o.com/SCRIPTS/ -- feel free to pick its brains)
DIRECTLY from the cheese shop, especially if you're using pip.
Oh, I also have pip at my repo (cd ../RPMS/noarch in my workbench).
See attached patch. I will log bugs where it corresponds too.
--
Manuel Amador (Rudd-O) <rudd-o(a)rudd-o.com>
Rudd-O.com - http://rudd-o.com/
GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/
Now playing, courtesy of Amarok: Aqua - Cartoon heroes
Windows 95 is not a virus. Viruses actually do something.
Hi,
I've just released a setuptools/distutils extension that makes the
process of compiling translations (i.e. .po -> .mo files) quite
automatic.
http://pypi.python.org/pypi/van.potomo/
However, one major problem is that to modify the function of the
setup.py "build" and "develop" commands one needs to do this in the
setup.py:
from setuptools import setup, find_packages
from van.potomo import develop, build
setup(
name = "HelloWorld",
cmdclass = {'build': build,
'develop': develop},
setup_requires = ["van.potomo"],
version = "0.1",
packages = find_packages(),
)
Meaning that you have to manually install van.potomo before tools like
buildout can run the setup.py to figure out the dependencies. Is there
any way to make that more automatic, especially so that buildout can
have a chance?
>From my experience with Debian, there's a "Build Dependencies" field in
the control file where one can specify such things. I'm kindof hoping
there's a setuptools equivalent?
I've searched for a while and most solutions involve monkey patching or
too much code in the setup.py.
--
Brian Sutherland
Hello distutils folks,
My group at Cisco uses easy_install / setuptools extensively for
installing packages with our make system and there are 2 issues with
using this with parallel make:
1. Duplicate dependencies cause corruption when installing the
same package twice.
2. easy-install.pth is never updated according to the installed
packages. Thus when we install 8+ packages and they all depend on
python being installed
3. Cross-compilation is impossible (at least with what I've seen
-- either that or the folks who hacked the sources before I got to it
didn't understand that feeding in the correct variables would ensure
that things could cross-compile). Then again many things Python don't
cross-compile from what I've seen :(... the interpreter itself is a
prime example =\.
My goal is to fix these issues and contribute back the fixes, but
I want to ensure that I use the best technical solution for the
problems I mentioned.
About problems 1 + 2:
I'm short on time so I'm going to implement a simple locking
mechanism around easy-install.pth. I also realize that .pth files are
chosen because they are flat files and are included simply from within
python with setup.py. Would it make more sense to use a backend
database like pysqlite to store the package data though? That would
require some reworking with setup.py, but considering that sqlite3 is
_already_ included with 2.5+ and it's a public domain licensed piece
of OSS software, would it make more sense to store packaging data with
a stable system like SQLite, especially when it would make removal a
trivial task? My knowledge of SQLite is limited, but I assume that it
supports the same level of endian neutral code that other technologies
like BDB do. Of course I'm going out on a huge limb in making that
assumption, but the only document I found that blatantly disproves my
claim straight out is
http://groups.google.com/group/wview/browse_thread/thread/6fcc993dd548206c/…
-- please correct me if I'm totally off-base.
Also, please let me know whether or not you disagree with my
proposal, and if there's a different method that could be employed
which could maximize data integrity, assure ATOMicity, and guarantee
that the data is endian neutral and thus portable to multiple
platforms.
About problem 3:
Is the solution simple enough to solve using --build, --host,
and/or --target, like configure, or does more gross work need to be
done under the covers to make things all work?
Thanks!
-Garrett
Hi,
Is it possible to include data in a source distribution?
I'd like to avoid eggs, since they don't integrate well with Gentoo packages,
but I didn't find a way to include data in a source distribution
(python setup.py sdist).
Did I miss something?
Best wishes,
Arne
--
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
At 06:20 PM 3/12/2009 +0100, Lennart Regebro wrote:
>I don't have many assumptions. I just want the setuptools install and
>tests to work as expected under both python2 and python3. And that
>means that python3.0 setup.py install should work. And python3.0
>setup.py test would be nice too, although it's less important.
In which case, either separate source distros are required, or 2to3
will need to be present, and the main setup.py will need to detect
python3 and run 2to3 on itself, then execfile the setup script of the
newly-generated, python3 version of the same package.
Please note that even if you make setuptools "not depend on itself",
all you are really doing is *moving* this problem to a different
level. Whatever it is that it depends on, will still need to be
duplicated for python2 and python3... and what's more, having a way
worked out to do this will be of benefit to other packages besides
setuptools, especially if setuptools provides some native support for
the feature. (Like a standardized "setup.py" and "setup3.py" that
delegate to the user's original 'setup2.py'.)