Created attachment 164584 [details] new line_profiler port Wanting to try out a python module called line_profiler I created a new port for it (shar file of what I have done attached), fairly simple setup, as it includes two scripts that are intended to be run from the cli I installed them into bin. As autoplist didn't pickup these two scripts I then added them to PLIST_FILES in the Makefile and concurrent then suffixes them correctly when needed. That's all fine and works for python 2.7 and 3.4 Now when I build using python 3.5 autoplist finds one of the scripts but not the other so I end up needing the following in the Makefile - .if ${PYTHON_VER} == 3.5 PLIST_FILES= bin/line_profiler .else PLIST_FILES= bin/line_profiler bin/kernprof .endif I'm not concerned if autoplist misses the two scripts as setting PLIST_FILES is easy enough, but it seems odd that one version will give different results.
A commit references this bug: Author: gahr Date: Thu Dec 24 14:53:48 UTC 2015 New revision: 404369 URL: https://svnweb.freebsd.org/changeset/ports/404369 Log: x11-wm/e16 - update to 1.0.17, take back maintainership Announce: https://sf.net/p/enlightenment/mailman/message/34341883 PR: 205565 Submitted by: gahr Approved by: gblach (for enlightenment@) Changes: head/x11-wm/e16/Makefile head/x11-wm/e16/distinfo
(In reply to commit-hook from comment #1) Typo in the PR line, please disregard.
Looking into this further shows the issue relates to me installing the scripts into bin. I did this as I started with py2.7 which fails to recognize the entry_points options in setup.py. This leaves me adding a PLIST_FILES entry and manually installing a script for py2.7 while py3.x works as expected. The real issue is that python 2.7 setupTools fails to recognize entry_points within setup.py, this leads to scripts not being created and installed into bin. /usr/local/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'entry_points'
Over to maintainer.
Created attachment 167563 [details] line_profile - makeplist 2.7 - 3.5 This log shows output for testing (auto)plist generation of line_profiler for python port versions 2.7 through 3.5 (using the respective py-setuptoolXY port) Given kernprof is the only command referenced as a console_script in setup.py [1], only kerneprof is expected in --record output in LOCALBASE/bin. The attached log shows that expected output. [1]: entry_points = { 'console_scripts': [ 'kernprof=kernprof:main', ], },
Created attachment 167565 [details] Fixed line_profiler Makefile Changes: shebangfix is unecessary for console_scripts, as setuptools rewrites the shebang line for the version of Python that the package is being build with already. The Cython port does not include PYTHON_PKGNAMEPREFIX. The BUILD_DEPENDS line was incorrect on this basis. Cython is only required as a build dependency for sources that have not been preprocessed (ie: raw from the repo), and not PyPI source distributions (sdists) Given only kernprof is references as a console_script, and setuptools --record output (which autoplist uses) contains this script in bin/, PLIST_FILES is unnecessary Custom installation of kernprof in post-install is unnecessary. My reading of the line_profiler README [1] only indicates kernprof as a CLI script, with line_profiler only for use as a programmatic module. In particular, the README specifically demonstrates use of line_profiler as follows: ``` python -m line_profiler ``` [1] https://github.com/rkern/line_profiler
Created attachment 167604 [details] my build output I had figured that kernprof was the only cli needed in bin. I didn't notice the prebuilt .c files coming from PyPi - though I think I first built from github before changing to PyPi Actually I am fairly convinced it is something on my machine that is broken. Using py27 and py33 I also cannot build python ports without also defining PYDISTUTILS_INSTALLNOSINGLE - py34 and py35 don't have that issue. I have tried rebuilding python27-2.7.11_1 and py27-setuptools27-20.0
Can you add an attachment that includes the output of ls -la /usr/local/lib/python2.7/site-packages (and another for 3.3) That might help indicate what might be going on.
Well listing py33 site-packages made it pretty clear as I only have that installed for testing % ls -la /usr/local/lib/python3.3/site-packages total 130 drwxr-xr-x 11 root wheel 15 28 Dec 16:16 . drwxr-xr-x 41 root wheel 198 28 Dec 16:07 .. -rw-r--r-- 1 root wheel 119 23 Dec 20:16 README drwxr-xr-x 2 root wheel 4 28 Dec 16:16 __pycache__ drwxr-xr-x 3 root wheel 5 28 Dec 16:16 _markerlib -rw-r--r-- 1 root wheel 185 28 Dec 03:31 easy-install.pth -rw-r--r-- 1 root wheel 185 28 Dec 03:31 easy-install.pth.dist -rw-r--r-- 1 root wheel 126 28 Nov 14:13 easy_install.py drwxr-xr-x 5 root wheel 5 8 Feb 2015 numpy drwxr-xr-x 2 root wheel 2 4 Dec 2014 numpy-1.8.1-py3.3.egg-info drwxr-xr-x 2 root wheel 2 5 Oct 2014 numpy-1.9.0rc1-py3.3.egg-info drwxr-xr-x 4 root wheel 5 28 Dec 16:16 pkg_resources drwxr-xr-x 4 root wheel 25 28 Dec 16:16 setuptools drwxr-xr-x 2 root wheel 9 28 Dec 16:16 setuptools-18.7-py3.3.egg-info drwxr-xr-x 2 root wheel 2 17 Oct 2014 setuptools-5.4.1-py3.3.egg-info % pkg info -ox py33 py33-setuptools33-18.7 devel/py-setuptools33 py33-sqlite3-3.3.5_7 databases/py-sqlite3 py33-tkinter-3.3.5_6 x11-toolkits/py-tkinter % pkg info -ox numpy py27-numpy-1.10.1,1 math/py-numpy py34-numpy-1.10.1,1 math/py-numpy py35-numpy-1.10.1,1 math/py-numpy Seems I got some old directories left behind in Oct 2014, while empty they cause the issue. Deleting the old egg entries for setuptools 5.4 fixes the issues - both entry_points and using PYDISTUTILS_INSTALLNOSINGLE - some thing for 2.7 and 3.3
Thanks for the feedback :)