I’m working on packaging a Python project that installs in a non-standard location. In order to do that, I would like to leverage setuptools as much as possible to replace the current manual installation. While exploring the various switches for setup.py install, I saw the --old-and-unmanageable flag with the cryptic help text “Try not to use this!”.
It looks like this is supposed to be a pass through to distutils.command.install.install, but it doesn’t seem to do anything different from the --root or --single-version-externally-managed options. I still see a .egg-info directory get installed and the package layout appears to be the same as the other options.
IIRC this allows setuptools to install directly to wherever. This is not compatible with wheels or PEP 517 workflows (they use wheels), as they can only install to select locations. Don’t use this flag
Well, I’m already trying to shove a Django project into an RPM, so I figured since I’m probably already deep into “don’t to that” territory what’s one more thing.
What would you recommend then? A custom setup.py command? This is a package that is going to be managed by yum so I wanted to leverage as many standard tools as possible.
If it’s for a one-off, then you may as well just copy files around manually. That’s all setuptools is doing - the only advantage is the interface if you’re trying to allow anyone to use your tools.
And if that last bit is true, and you’re building a generic tool, then you’ll want to build it around wheels (which you’ll extract into place), and let whoever is providing the projects do so as wheels. That way you don’t have to enforce any tool for them to use - the interchange format is what’s specified.
It’s implied by both Steve and Filipe’s comments, but I want to spell it out explicitly: this really depends on what you are trying to achieve. If you are building a redistributable Python package (i.e. something you can put on pypi.org or a on-premise equivalent), you should look into wheels and PEP 517. If you just want a framework to write scripts for building and copying files around, it’s usually better to write it manually. The bottom line is, setup.py install has too much magic, and while it can do what you want, almost always also gives you too much that you don’t, and those tend to cause problems down the road. (It’s generally fine to do other comamnds, such as setup.py build if you need to build some C extensions, just not setup.py install).