What does setup.py install --old-and-unmanageable actually do?

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.

What is this option supposed to do?

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 :stuck_out_tongue_winking_eye:

If you can, don’t even use setup.py install in the first place (not always viable, but please try).

1 Like

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.

As a distro packager, putting a django app in a RPM seems fine to me.

There is no replacement yet, unless you consider pip a valid solution. See PEP 517 workflow for distributions for a detailed explanation. Essentially, the replacement would be to build a wheel (with GitHub - pypa/build: A simple, correct PEP 517 package builder), and then install it, but currently there isn’t any useful wheel installer other than pip.

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).