[Numpy-discussion] Development workflow (not git tutorial)

[Nathaniel Smith]

On Aug 14, 2015 09:16, "Chris Barker" <chris.barker at noaa.gov> wrote:
>
> On Thu, Aug 13, 2015 at 11:25 AM, Stefan van der Walt <
stefanv at berkeley.edu> wrote:
>>
>> >(for
>> > example "python setup.py develop", although suggested by
>> > setup.py itself, claims that "develop" is not a command).
>
>
> develop is a command provided by setuptools, not distutils itself.
>
> I find it absolutely invaluable -- it is THE way to go when actively
working on any package under development.
>
> if numpy doesn't currently use setuptools, it probably should (though
maybe it's gets messy with numpy's distutils extensions...)

Regarding using setuptools by default, one problem is that it actually acts
rather differently from distutils by default. See

https://bitbucket.org/pypa/setuptools/issues/371/setuptools-and-state-of-pep-376

>> Nowadays, you can use
>>
>> pip install -e .
>
>
> pip "injects" setuptools into the mix -- so this may be develope mode
with a different name. but yes, a fine option for a package that doesn't
use setuptools out of the box.

The version of setuptools that pip injects is also monkeypatched by pip to
fix some of setuptools more obnoxious defaults. (The ones described in that
bug report.) Using pip is also is the only way to reliably install all the
right metadata needed to avoid problems later -- in particular pip will
record the information needed to do uninstall/upgrades correctly, which
neither distutils nor setuptools will do if you run setup.py directly.

Basically this means running 'setup.py install' is always broken, for all
projects and no matter how setup.py is written, and you should always run a
pip command instead, even when building from the source tree. This is true
for every python package, though, not just numpy. So setuptools doesn't
provide much that's compelling for us...

I believe if you really want it, though, you can run numpy's setupegg.py,
which is the same as setup.py but using setuptools. Or something like that?

I share Benjamin's doubts about the whole 'develop' approach, though,
however accessed. For pure python packages, just importing from the source
tree directly works fine and is way less error prone. For non-pure
packages, I don't trust develop much anyway... build_ext --inplace can work
nicely, or for numpy in particular runtests solves all my problems. (Though
even then I still sometimes need to nuke the build directory or run clean
manually.)

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150814/9e2aa685/attachment.html>