Test (and develop) command should use package built in "build" directory rather than in place
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2.9k
- Forks
- 1.4k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 1
Description
Originally reported by: callegar (Bitbucket: callegar, GitHub: callegar)
When using the test command, a setup script using setuptools builds the package in place and then runs the test from there. In fact, this is documented:
python setup.py --help-commands
...
test run unit tests after in-place build
...
However, this has a few issues:
- It is inconsistent with the
build,install,bdistcommands, that build in a subdirectory of thebuilddirectory named after the system architecture and python version, for instancebuild/lib.linux-x86_64-2.7. - It is inefficient, because after you
build, you end up building again in-place for testing. For packages with a lot of C or Cython extensions, this can waste a significant amount of time.
Most important:
- It is troublesome when you have a home directory that is shared among multiple machines with different architectures. For instance suppose that you have a 32 bit (i386) and a 64 bit (x86_64) systems with a shared home. When you move from one system to another, you end up with your project directory containing binary files that make no sense in your architecture and that can cause issues. The same happens if you have your project directory in an area that is synched by services like unison, dropbox, owncloud, etc. among different systems. As a matter of fact, the main reason for having a separate build directory is not keeping the source tree tidy, but nicely handling multiple platforms/architectures. Unfortunately, this is correctly provided for the
build,bdistandinstallcommands but then suddently broken fortest(and probablydevelop).
I do not think that I can mark the current behavior as a bug, since in the end it is the documented behavior. Hence, I am marking it as an enhancement. But still I think that it is problematic and that it should be fixed.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the setup script and the implementations of the test, develop, build, install, and bdist commands. Compare how test locates and builds the package with the existing build-directory behavior, including the architecture and Python-version path described in the issue. Done means testing uses the built package without rebuilding in place or leaving architecture-specific binaries in the source tree.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100