Re: [Numpy-discussion] Problems using add_npy_pkg_config

2015-08-15 Thread Ralf Gommers
On Fri, Aug 14, 2015 at 11:25 PM, Christian Engwer 
christian.eng...@uni-muenster.de wrote:

 Dear Ralf,

  I stared at it for a while, and can't figure it out despite you following
  the example in the add_npy_pkg_config docstring pretty much to the
 letter.
  When you see that the error is generated in a function that starts with
 ``#
  XXX: another ugly workaround to circumvent distutils brain damage.``,
  you're usually in trouble.

 what a pity... do you have an alternative suggestion? Is there a good
 alternative, e.g. using cmake, to distribute python modules?


I wouldn't give up on distutils here (yet). For distributing/installing
python packages, PyPi + pip are the de-facto standard and pip is currently
tied to distutils/setuptools unfortunately.

That I can't figure out your issue in 20 minutes doesn't mean it's not
fixable, it just means that I'm not smart enough to keep the distutils
design in my head:)

The code you're trying to use isn't well tested because while a lot of
packages use numpy.distutils with compiled code, very few Python packages
expose a C API. For example Scipy doesn't use `add_npy_pkg_config` or
`add_installed_library` at all. Those functions work for numpy itself
though, so they can't be completely broken.

If no one has an answer here, what I would do if I were you is break out
your debugger and figure out what's in `pkg` when you build numpy itself
and why it's None when you build your own code.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Problems using add_npy_pkg_config

2015-08-15 Thread Ralf Gommers
On Sat, Aug 15, 2015 at 11:19 AM, Ralf Gommers ralf.gomm...@gmail.com
wrote:




 On Fri, Aug 14, 2015 at 11:25 PM, Christian Engwer 
 christian.eng...@uni-muenster.de wrote:

 Dear Ralf,

  I stared at it for a while, and can't figure it out despite you
 following
  the example in the add_npy_pkg_config docstring pretty much to the
 letter.
  When you see that the error is generated in a function that starts with
 ``#
  XXX: another ugly workaround to circumvent distutils brain damage.``,
  you're usually in trouble.

 what a pity... do you have an alternative suggestion? Is there a good
 alternative, e.g. using cmake, to distribute python modules?



 I wouldn't give up on distutils here (yet). For distributing/installing
 python packages, PyPi + pip are the de-facto standard and pip is currently
 tied to distutils/setuptools unfortunately.


Correction: the above is only completely true if you rely on source builds.
You can't avoid those with PyPi on Linux, but if you only need to support
Windows and OS X nowadays you can get away with no disutils if you upload
only binary wheels for those OSes to PyPi.

Regarding alternatives, this discussion is a bit older but mostly still
relevant: http://article.gmane.org/gmane.comp.python.numeric.general/27788

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


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

2015-08-15 Thread Ralf Gommers
On Sat, Aug 15, 2015 at 1:08 AM, Pauli Virtanen p...@iki.fi wrote:

 15.08.2015, 01:44, Chris Barker kirjoitti:
 [clip]
  numpy doesn't use namespace packages, so develop mode works there.

 The develop mode is mainly useful with a virtualenv.

 Otherwise, you install work-in-progress development version into your
 ~/.local which then breaks everything else. In addition to this, python
 setupegg.py develop --uninstall says Note: you must uninstall or
 replace scripts manually!, and since the scripts end up with dev
 version requirement hardcoded, and you have to delete the scripts manually.

 Virtualenvs are annoying to manage, and at least for me personally it's
 easier to just deal with pythonpath, especially as runtests.py manages
 that.


I completely agree. Virtualenv/pip/setuptools all too many issues and
corner cases where things don't quite work for development purposes. Using
runtests.py is the most reliable approach for working on numpy (or just use
an in-place build + pythonpath management if you prefer).


To get back to the original question of Anne (as well as the gdb one): most
of what was said and recommended in this thread is fairly well documented
in
https://github.com/numpy/numpy/blob/master/doc/source/dev/development_environment.rst

Unfortunately it doesn't yet show up in
http://docs.scipy.org/doc/numpy-dev/dev/index.html because that hasn't been
updated in a while. If someone who knows how to do that could push an
update, that would be great.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion