Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

labels subcommand broken by default python #123

Closed
vpipkt opened this issue Dec 5, 2018 · 5 comments · Fixed by #124
Closed

labels subcommand broken by default python #123

vpipkt opened this issue Dec 5, 2018 · 5 comments · Fixed by #124

Comments

@vpipkt
Copy link

vpipkt commented Dec 5, 2018

The labels subcommand runs the stream_filter.py code as a separate process using the system's default python. In my case that was python 2.7 and shapely was not installed so I found this through ImportError.

In general that is confusing and could lead to incorrect behavior or non-deterministic results.

run(['python', stream_filter_fpath, json.dumps(bounding_box)],

@drewbo
Copy link
Contributor

drewbo commented Dec 6, 2018

@vpipkt good find. It's set up in this slightly rickety manner so that we can pipe from tippecanoe-decode directly to this function. Do you have an idea of how we can do this natively? We might need to call tippecanoe in a different way but I'm not very familiar with writing Python bindings for C++ libraries; it looks like there are a few examples of python-tippecanoe attempts but nothing very well maintained.

@vpipkt
Copy link
Author

vpipkt commented Dec 6, 2018

I have a slightly less rickety idea...

Use sys.executable in place of 'python' in the list to run. That seems to work with pip install label-maker. It recovers the expected interpreter in the shebang line of the label-maker script. Which in my case was the same python used to install pip.

Of interest when I was researching this, I found this footnote:

On Unix, the Python 3.x interpreter is by default not installed with the executable named python, so that it does not conflict with a simultaneously installed Python 2.x executable.

Given that note an alternative may be to use 'python3.6'.

@drewbo
Copy link
Contributor

drewbo commented Dec 6, 2018

@vpipkt I did a few quick checks in different environments and the sys.executable seems to work well. I'll put up a PR later today unless you have one ready

@wronk wronk closed this as completed in #124 Dec 7, 2018
wronk added a commit that referenced this issue Dec 7, 2018
Use sys.exectuable in place of python string, close #123
@drewbo
Copy link
Contributor

drewbo commented Dec 7, 2018

@vpipkt you can install from source right now and get this fix or I'll include it in the next release 0.5.2

@vpipkt
Copy link
Author

vpipkt commented Dec 7, 2018

@drewbo thanks much! I used alternatives to make sure things ran for me... just include this in the next release!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants