Bug 205565 - devel/py-setuptools27: failure to recognize entry_points
Summary: devel/py-setuptools27: failure to recognize entry_points
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kubilay Kocak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-24 07:51 UTC by Shane
Modified: 2016-03-02 16:27 UTC (History)
1 user (show)

See Also:
koobs: maintainer-feedback+


Attachments
new line_profiler port (2.67 KB, application/x-shar)
2015-12-24 07:51 UTC, Shane
no flags Details
line_profile - makeplist 2.7 - 3.5 (4.43 KB, text/plain)
2016-02-29 13:32 UTC, Kubilay Kocak
no flags Details
Fixed line_profiler Makefile (1.18 KB, text/plain)
2016-02-29 13:39 UTC, Kubilay Kocak
no flags Details
my build output (16.46 KB, text/x-log)
2016-03-01 09:47 UTC, Shane
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shane 2015-12-24 07:51:20 UTC
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.
Comment 1 commit-hook freebsd_committer 2015-12-24 14:53:58 UTC
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
Comment 2 Pietro Cerutti freebsd_committer 2015-12-24 15:05:41 UTC
(In reply to commit-hook from comment #1)

Typo in the PR line, please disregard.
Comment 3 Shane 2015-12-29 03:30:24 UTC
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'
Comment 4 Raphael Kubo da Costa freebsd_committer 2016-02-28 21:57:42 UTC
Over to maintainer.
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2016-02-29 13:32:21 UTC
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',
        ],
    },
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2016-02-29 13:39:12 UTC
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
Comment 7 Shane 2016-03-01 09:47:07 UTC
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
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2016-03-01 12:06:16 UTC
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.
Comment 9 Shane 2016-03-02 09:55:36 UTC
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
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2016-03-02 16:27:33 UTC
Thanks for the feedback :)