PBR

Incomplete support for packages_root field in setup.cfg

Bug #1686111 reported by Simon Ruggier
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
PBR
Confirmed
Medium
Unassigned

Bug Description

I recently tried to get pbr to work with a source tree layout where the code is under a src/ subdirectory, but despite my best efforts, I was unsuccessful. In the [files] section of my setup.cfg, I set packages_root = src, and then tried various different values for packages, such as <packagename>, src.<packagename>, src/<packagename>, and just src, and none of those resulted in the successful creation of packages. I've attached a simple repro tarball to illustrate what I mean. One can extract the tarball, run git init to keep pbr's automatic versioning happy, and then play with setup.py commands in there.

Revision history for this message
Simon Ruggier (simon80) wrote :
Revision history for this message
Gaetan Semet (gaetan-xeberon) wrote :

Indeed, it does not seems to work out of the box.

I tried:

[files]
packages_root = src
files = src # or src/mypackage

It does not work. Would be cool to allow packages to be put into a subdirectory "src", without changing the name of the package and the way to access to it

also, it allows more easily package transitions:
In my package, I have a src/mypackage package. Now, let's say I have some method I want to move to another lib "anotherlib". I can temporarily create an src/anotherlib", time until pypi receive my new lib 'anotherlib', and I do not have code to change in python files.

Revision history for this message
Andrew Grigorev (ei-grad) wrote :

Putting the code to src/ folder looks a good practice, and it is sad that I can't use pbr for such project structure :-(.

Revision history for this message
Andrew Grigorev (ei-grad) wrote :

Steps to reproduce:

```
mkdir simplepkg/src/simplepkg
cd simplepkg
git init
```

src/simplepkg/__init__.py:
```
print("Hello, world!")
```

setup.py:
```
#!/usr/bin/env python

from setuptools import setup

setup(
    setup_requires=['pbr'],
    pbr=True,
)
```

setup.cfg:

```
[metadata]
name = simplepkg

[files]
packages_root = src/
packages =
    simplepkg
```

Create virtualenv and install our package:

```
python -m venv env
source env/bin/activate
pip install .
python -c 'import simplepkg'
```

The output is:

```
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'simplepkg'
```

Ben Nemec (bnemec)
Changed in pbr:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Kyle T Stapp (rabidcicada) wrote :

I have noticed this also. If you run a 'pip install .' in the git checked out directory it doesn't work...but if you run 'python setup.py install' it does work. It happens at. Low level as I put debug statements in setuptools, distribute, and pbr. And dist itself finds no packages with 'has_pure_python'. And indeed it finds no packages in general. I'll perform more debugging. This is high on my list because I want the other machinery provided by pbr.

Revision history for this message
Kyle T Stapp (rabidcicada) wrote :

Sorry for the terrible description above. This is still a real problem. But I found a way to still get the functionality of pbr to work while still using setuptools properly.

Put the `package_dir={'':'src/'} in the setup.py (this is needed as per a warning on https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files under "Using find_packages".

Put an [options] section in setup.cfg since setuptools supports setup.cfg style config now. Specify
[options]
package_dir = src/
packages = boardgame_framework

SetupTools will accept that info and still play well with pbr. Stop using [files] section of pbr.

You still get all the autogeneration goodness of pbr with authors, changelog, version number, release notes, etc....and you get proper sdist and installs!

I plan to keep looking at the behavior in pbr to see if I can fix it but I'm putting this info here in case a "real" pbr developer can connect the dots on what info is not being forwarded around properly.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.