Re: [openstack-dev] [pbr] support for 'python setup.py install'
I realised it was worse than that - see the review. On 26 April 2015 at 07:11, Robert Collins robe...@robertcollins.net wrote: On 26 April 2015 at 01:49, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-04-25 12:12:15 +1200 (+1200), Robert Collins wrote: [...] I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install. [...] And emit a clear error message? (Even if that just means updating the setup.py boilerplate in the cookiecutter repo and encouraging projects to adopt the function.) No. Sadly python setup.py install *with deps already present* is something that many install tools - e.g. buildout is a not-uncommon one - other than pip use (and as mentioned later in this thread, pip itself uses setup.py install when the wheel dep is not present). Testing that it works with no deps installed is testing easy_install, which we don't care about. Forcing it not to work doesn't buy us anything except knowing that our tooling will blow up hard if easy_install is ever triggered. I guess if we take a truely minimal view on this it might be ok. I'll update my review of the patch with that. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [pbr] support for 'python setup.py install'
On 26 April 2015 at 01:49, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-04-25 12:12:15 +1200 (+1200), Robert Collins wrote: [...] I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install. [...] And emit a clear error message? (Even if that just means updating the setup.py boilerplate in the cookiecutter repo and encouraging projects to adopt the function.) No. Sadly python setup.py install *with deps already present* is something that many install tools - e.g. buildout is a not-uncommon one - other than pip use (and as mentioned later in this thread, pip itself uses setup.py install when the wheel dep is not present). Testing that it works with no deps installed is testing easy_install, which we don't care about. Forcing it not to work doesn't buy us anything except knowing that our tooling will blow up hard if easy_install is ever triggered. I guess if we take a truely minimal view on this it might be ok. I'll update my review of the patch with that. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [pbr] support for 'python setup.py install'
On 04/25/2015 09:49 AM, Jeremy Stanley wrote: On 2015-04-25 12:12:15 +1200 (+1200), Robert Collins wrote: [...] I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install. [...] And emit a clear error message? (Even if that just means updating the setup.py boilerplate in the cookiecutter repo and encouraging projects to adopt the function.) Unfortunately there is no way to detect that you're being run via setup.py install instead of pip. What will happen though is that easy_install will get triggered instead of egg_info/pip install ... so we _could_ just do something to try to emit a warning around one of the easy_install classes ... __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [pbr] support for 'python setup.py install'
On 04/24/2015 08:12 PM, Robert Collins wrote: In our pbr integration tests we ensure that 'python setup.py install' works, as well as ensuring that 'pip install' works. But see http://lists.openstack.org/pipermail/openstack-dev/2013-September/015525.html - for the last 18 months in pbr we've treated complains that setup.py install fails as a reason to say 'use pip install .'. I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install. This would relegate setup.py to building, not installation, which is what its intended to be these days. Thoughts? Yes. python setup.py install is completely unsupportable. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [pbr] support for 'python setup.py install'
On 2015-04-25 12:12:15 +1200 (+1200), Robert Collins wrote: [...] I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install. [...] And emit a clear error message? (Even if that just means updating the setup.py boilerplate in the cookiecutter repo and encouraging projects to adopt the function.) -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [pbr] support for 'python setup.py install'
I'm not going to pretend it is graceful... but is there a situation where _ isn't correct? $ cat setup.py #!/usr/bin/env python from distutils.core import setup as _setup import os def new_setup(**attrs): if pip not in os.environ.get(_): raise SystemExit(Please use pip to install) else: _setup(**attrs) setup = new_setup setup(name='foobar', version='1.0', description='Foobar', ) -- Kind Regards, Dave Walker On 25 April 2015 at 15:27, Monty Taylor mord...@inaugust.com wrote: On 04/25/2015 09:49 AM, Jeremy Stanley wrote: On 2015-04-25 12:12:15 +1200 (+1200), Robert Collins wrote: [...] I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install. [...] And emit a clear error message? (Even if that just means updating the setup.py boilerplate in the cookiecutter repo and encouraging projects to adopt the function.) Unfortunately there is no way to detect that you're being run via setup.py install instead of pip. What will happen though is that easy_install will get triggered instead of egg_info/pip install ... so we _could_ just do something to try to emit a warning around one of the easy_install classes ... __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [pbr] support for 'python setup.py install'
On 04/25/2015 11:33 AM, Dave Walker wrote: I'm not going to pretend it is graceful... but is there a situation where _ isn't correct? Ooh. This is a worthy avenue to explore ... $ cat setup.py #!/usr/bin/env python from distutils.core import setup as _setup import os def new_setup(**attrs): if pip not in os.environ.get(_): raise SystemExit(Please use pip to install) else: _setup(**attrs) setup = new_setup setup(name='foobar', version='1.0', description='Foobar', ) -- Kind Regards, Dave Walker On 25 April 2015 at 15:27, Monty Taylor mord...@inaugust.com wrote: On 04/25/2015 09:49 AM, Jeremy Stanley wrote: On 2015-04-25 12:12:15 +1200 (+1200), Robert Collins wrote: [...] I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install. [...] And emit a clear error message? (Even if that just means updating the setup.py boilerplate in the cookiecutter repo and encouraging projects to adopt the function.) Unfortunately there is no way to detect that you're being run via setup.py install instead of pip. What will happen though is that easy_install will get triggered instead of egg_info/pip install ... so we _could_ just do something to try to emit a warning around one of the easy_install classes ... __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [pbr] support for 'python setup.py install'
On 04/25/2015 11:46 AM, Monty Taylor wrote: On 04/25/2015 11:33 AM, Dave Walker wrote: I'm not going to pretend it is graceful... but is there a situation where _ isn't correct? Ooh. This is a worthy avenue to explore ... Ok. After some chatting with fungi in IRC - I've got this: https://review.openstack.org/177557 It finds direct invocations and fails. It works with pip - and it handles distro-packaging invocation paths appropriately. It also gives a very lengthy error message that makes it clear what a user should do. $ cat setup.py #!/usr/bin/env python from distutils.core import setup as _setup import os def new_setup(**attrs): if pip not in os.environ.get(_): raise SystemExit(Please use pip to install) else: _setup(**attrs) setup = new_setup setup(name='foobar', version='1.0', description='Foobar', ) -- Kind Regards, Dave Walker On 25 April 2015 at 15:27, Monty Taylor mord...@inaugust.com wrote: On 04/25/2015 09:49 AM, Jeremy Stanley wrote: On 2015-04-25 12:12:15 +1200 (+1200), Robert Collins wrote: [...] I'd like to make that a little more official: - put it in our docs - stop testing python setup.py install. [...] And emit a clear error message? (Even if that just means updating the setup.py boilerplate in the cookiecutter repo and encouraging projects to adopt the function.) Unfortunately there is no way to detect that you're being run via setup.py install instead of pip. What will happen though is that easy_install will get triggered instead of egg_info/pip install ... so we _could_ just do something to try to emit a warning around one of the easy_install classes ... __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
