Question: Migrating from distutils to setuptools

[WildCard65]

Hello, I recently helped a project migrate from distutils to setuptools BUT a snag was discovered. One of the things that was swapped was using a provided python script to the 'console_scripts' entry point.

Unfortunately, this causes an issue when upgrading installations as setuptools doesn't error out the install should it detect a previous version was installed with distutils. Is there anything inside setuptools that could make this easier for the project?

Pinging @dvander as he owns/maintains the project in question Cross reference issue: https://github.com/alliedmodders/ambuild/issues/68

[pganssle]

I think we need more context here. It sounds like you are having a problem when someone invokes setup.py install?

If that's the case, then the best solution is to always use pip install. We're working to deprecate setup.py install but it's a bit complicated to emit an error message only at the right times for that. Regardless, we stopped supporting setup.py install in all situations where pip install works a few years ago.

[WildCard65]

@pganssle No, the issue is the distutils pre-installed previous version renders the console_script a mute object as it raises an ImportError that it can't find the entry point, see the referenced issue.

[pganssle]

That whole issue seems to be that setup.py install can't uninstall distutils-installed packages, and the desired behavior (raising an error) is what happens when you use pip install.

If I've misunderstood, can you give a short self-contained example that demonstrates your issue without invoking setup.py install, along with the desired behavior?

As an aside, thank you for trying to keep projects' packaging code up to date!

[WildCard65]

Actually, it seems more like the issue is setuptools doesn't attempt to uninstall the previous installation and when the console script goes to import, it actually imports the previous version.

[WildCard65]

Another thing to note is that the project is generally installed via DIRECT invocation of 'setup.py'

References: https://github.com/alliedmodders/sourcemod/blob/master/tools/checkout-deps.sh#L143 https://github.com/alliedmodders/metamod-source/blob/master/support/checkout-deps.sh#L73 https://github.com/alliedmodders/amxmodx/blob/master/support/checkout-deps.sh#L92 https://github.com/alliedmodders/sourcepawn/blob/master/tools/checkout-deps.sh#L29 https://github.com/alliedmodders/amtl/blob/master/checkout-deps.sh#L33

[pganssle]

Actually, it seems more like the issue is setuptools doesn't attempt to uninstall the previous installation and when the console script goes to import, it actually imports the previous version.

To be honest, I'm always surprised when someone invokes python setup.py install and it doesn't completely break their Python environment, so I guess I'm not surprised by that. Like I said earlier, we're really not supporting setup.py install, so I don't think there's much we can do here other than deprecate it as soon as humanly possible.

Soon we will have completed our adoption of distutils and hopefully we can start issuing deprecation warnings even for setup.py install using distutils (as long as setuptools is installed). Until then, I think your best bet is to do your best to suggest that your users use pip install instead of setup.py install. If you'd like to investigate how to deprecate setup.py install without it also raising deprecation warnings when a wheel is built, I think a PR doing that would be very welcome.

[WildCard65]

I'm calling @dvander here now as this is something you'll need to explain to him. Edit: Thanks for the input anyway, I figured as much that pip is the way to go as it's how any package is installed.

[pganssle]

OK, it seems that there's no action we can take here so I'll close this issue for now. Sorry we didn't have a better solution for you.