Hi All,
Given a distribution name (ie: one of those things setuptools uses,
'name' parameter to setup.py's setup call, etc) of a dsitrbution that
has been installed with easy_install, buildout, pip, etc, how can I find
out what python packages (ie: dotted names that I can import) are
provided by that package?
I'm trying to write a scanner than looks for SQLAlchemy table objects
and it would be great to be able to pass a distribution name rather than
a set of dotted package names...
cheers,
Chris
Hi,
having a problem with my buildout and like to request some hints.
I have a buildout which creates a simple python interpreter environment
like explained in the buildout manual. Additionally I use a custom
script.
My problem is: How can I tell my_recipe to use the (newly created)
mypython interpreter, instead of using the standard python interpreter?
Or as a workaround: Is there a way to install the custom interpreter
before the buildout, maybe on bootstrap?
I like to avoid using virtualenv.
TIA and cheers
Udo Spallek
------------
buildout.cfg
------------
[buildout]
parts = mypython
myrecipe
[mypython]
recipe = zc.recipe.egg
interpreter = mypython
eggs =
relatorio
[myrecipe]
recipe = my_recipe
interpreter = mypython # This doesn't work
At 11:36 AM 8/12/2010 +0530, pavi ena wrote:
>Scripts\python.exe setup.py install -vvv
Change the above line to:
Scripts\python.exe setup.py build -b btmp install -vvv
If this change makes it work, then the problem is indeed the bug
pointed out by Takayuki SHIMIZUKAWA:
http://bugs.python.org/issue6884
Otherwise, I'm not sure what's going on.
Hi All,
I'm pleased to announce a new release of buildout-versions.
This release:
- Makes Buildout Versions check its own version has been pinned.
- Makes Buildout’s version constraints agnostic of the case of
distribution names.
- Has a bit of a documentation tidy-up.
The PyPI page is here:
http://pypi.python.org/pypi/buildout-versions
The documentation is here:
http://packages.python.org/buildout-versions/use.html
If you have any problems or suggestions, please let me know on this list
or the Simplistix open source google group!
cheers,
Chris
Hi,
What's the best way to bundle tests into a test archive for a distribution using distribute or setuptools?
My requirements:
* Tests should not be installed because the testsuite is larger than the actual package and not generally usefull
* "python setup.py develop" should also not add the testsuite to sys.path
* Some tests use extensions that are part of the testsuite
* It should be possible to use "python setup.py test" to run the testsuite
My current directory layout is simular to the CPython tree:
* toplevel setup.py script
* Lib/ contains modules/packages
* Modules/ contains extension source
* TestSuite/ contains the unittests
The setup.py file contains a package_dir declaration:
package_dir = { '': 'Lib', 'TestSuite': 'TestSuite' },
I also have a custom build_ext command to ensure that extensions in the testsuite get copied there during the build phase
(as if the inplace option is selected for just those extensions).
This works but feels rather fragile, and I wonder if there is a cleaner solution for meeting my requirements.
(I'm using plain unittest for the tests and will probably switch to unittest2 in the near future)
Ronald
At 08:37 AM 8/17/2010 -0500, Brad Allen wrote:
>I am not sure if this got lost in the shuffle, but Praveen said this
>problem only occurs if the package name begins with the string
>"build". The problem doesn't occur if the package is renamed to
>something else.
That's why I gave the instructions that I did.
The likely problem is that distutils is doing an exclusion on the
"build" directory -- but it uses the "build base" directory to
determine the exclusion, i.e.:
self.filelist.exclude_pattern(None, prefix=build.build_base)
This means you can (probably) work around the issue by adding "build
-b btmp", so that the exclusion is applied to files beginning with
'btmp' instead of with 'build'.
Hence, the instructions you see below:
>On Thu, Aug 12, 2010 at 10:05 PM, P.J. Eby <pje(a)telecommunity.com> wrote:
> > At 11:36 AM 8/12/2010 +0530, pavi ena wrote:
> >>
> >> Scripts\python.exe setup.py install -vvv
> >
> > Change the above line to:
> >
> > Scripts\python.exe setup.py build -b btmp install -vvv
> >
> > If this change makes it work, then the problem is indeed the bug
> pointed out
> > by Takayuki SHIMIZUKAWA:
> >
> > http://bugs.python.org/issue6884
> >
> > Otherwise, I'm not sure what's going on.
Hi All,
The following buildout.cfg demonstrates something that feels buggy to me:
[buildout]
parts = sqlalchemy migrate
versions = versions
[versions]
SQLAlchemy = 0.6.0
sqlalchemy = 0.6.2
[sqlalchemy]
recipe = zc.recipe.egg
eggs = SQLAlchemy
entry-points = foo=bar:baz
[migrate]
recipe = zc.recipe.egg
eggs = sqlalchemy-migrate
When run, you'll get two scripts:
bin/migrate:
...
sys.path[0:0] = [
'/opt/buildout-eggs/sqlalchemy_migrate-0.6-py2.6.egg',
'/opt/buildout-eggs/Tempita-0.4-py2.6.egg',
'/opt/buildout-eggs/decorator-3.2.0-py2.6.egg',
'/opt/buildout-eggs/SQLAlchemy-0.6.2-py2.6.egg',
...
bin/foo:
...
sys.path[0:0] = [
'/opt/buildout-eggs/SQLAlchemy-0.6.0-py2.6.egg',
]
...
The problem is that sqlalchemy-migrate declares an install_requires
dependency on "sqlalchemy", which the package is actually called SQLAlchemy.
It could be argued that sqlalchemy-migrate is "wrong" but it remains
that all python's packaging tools appear case insensitive to package names.
As such, I'd expect buildout's version pinning to be case agnostic as
well. What do other people feel about this?
Chris
At 07:48 PM 8/11/2010 +0530, pavi ena wrote:
>The above said scenario is working fine with Linux machine when i
>tried the same usecase in windows machine, it is not working as expected.
>Entry point console script is not listing/showing under "Scripts" directory.
Where is it showing up? Note that on Linux, the standard
installation pattern is such that scripts are installed in prefix/bin
-- i.e., alongside the python executable. On Windows, however, the
default installation location for scripts is in a subdirectory called
"Scripts" alongside the python executable.
Since you did a verbose install, the actual location of the script
should be shown in the output from the command.
Hello,
While working with setuptools [Automatic Script Creation with setuptools]
module to build python package naming with "build" as prefix for package
name, i found wired issue with setup.py. My setup.py code looks like below.
from setuptools import setup, find_packages
setup(
name=*'build_tools'*,
version='0.1.0',
packages = find_packages(),
entry_points = {
'console_scripts': [
'test_build = test_build:main',
],
},
)
F:\mywork\*build_tools*>Scripts\python.exe setup.py install -vvv [this is
how i executed the setup.py from virtual python]
After running the above installer, as per my understanding after the
successful installation of this package the console entry_points should go
in to the "Scripts" directory.
The above said scenario is working fine with Linux machine when i tried the
same usecase in windows machine, it is not working as expected.
Entry point console script is not listing/showing under "Scripts" directory.
Please any one suggest fix or explain me the problem.
Thanks,
Praveen Doddamani.
At 02:57 PM 8/11/2010 +0200, Mathieu Leduc-Hamel wrote:
>If you install the package with the satchmo support like that:
>
>storelocator[satchmo]
>
>Then I would like be able with pkg_resources or something like to
>check in the code if the satchmo support has been enabled or not, if
>yes, i'll change some part of my package or not.
try:
pkg_resources.require('storelocator[satchmo]')
except pkg_resources.ResolutionError:
pass # failure case
else:
pass # success case
