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

supporting __file__ correctly in setup.py #770

Closed
asmodehn opened this issue Dec 13, 2015 · 5 comments
Closed

supporting __file__ correctly in setup.py #770

asmodehn opened this issue Dec 13, 2015 · 5 comments

Comments

@asmodehn
Copy link
Contributor

We should probably define __file__ around there https://github.com/ros/catkin/blob/indigo-devel/cmake/interrogate_setup_dot_py.py#L244
So that setup.py is used the same way as it would from python cli.

At the moment interrogate_setup_dot_py breaks on simple setup.py :

Interrogating setup.py for package python_tblib into /home/alexv/Projects/python-tblib-rosrelease/build/catkin_generated/setup_py_interrogation.cmake 
Traceback (most recent call last):
  File "/opt/ros/indigo/share/catkin/cmake/interrogate_setup_dot_py.py", line 252, in <module>
['/opt/ros/indigo/share/catkin/cmake/interrogate_setup_dot_py.py', 'python_tblib', '/home/alexv/Projects/python-tblib-rosrelease/setup.py', '/home/alexv/Projects/python-tblib-rosrelease/build/catkin_generated/setup_py_interrogation.cmake']
executing /home/alexv/Projects/python-tblib-rosrelease/setup.py
    main()
  File "/opt/ros/indigo/share/catkin/cmake/interrogate_setup_dot_py.py", line 243, in main
    execfile(args.setupfile_path,{})
  File "/home/alexv/Projects/python-tblib-rosrelease/setup.py", line 13, in <module>
    long_description=open(os.path.join(os.path.dirname(__file__), 'README.rst')).read(),
NameError: name '__file__' is not defined

which can prevent doing third party release of simple python packages.
https://github.com/asmodehn/python-tblib-rosrelease/blob/release/indigo/python_tblib/setup.py

IDLE used to have a similar bug, we might want to get some inspiration from their fix :
http://bugs.python.org/issue8515

@dirk-thomas
Copy link
Member

I have created #771 to address your use case. Can you please try it with the patched version of catkin and confirm that it solves your use case.

@asmodehn
Copy link
Contributor Author

Thanks !
It seems it solves the cmake step (tested on a simple checkout):

-- Using CATKIN_DEVEL_PREFIX: /home/alexv/Projects/python-tblib-rosrelease/build/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/indigo
-- This workspace overlays: /opt/ros/indigo
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /home/alexv/Projects/python-tblib-rosrelease/build/test_results
-- Found gtest sources under '/usr/src/gtest': gtests will be built
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.6.16
*** Arguments ['include_package_data', 'zip_safe'] to setup() not supported in catkin devel space in setup.py of python_tblib
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alexv/Projects/python-tblib-rosrelease/build

So this fix is good to go in, I think.

But then make does nothing (because of the warnings about the devel space ?).
make install seems to work fine though, similar output as if I run python setup.py install.
Not sure how this will affect the release...

@dirk-thomas
Copy link
Member

Good, so the patch seems to work as expected then.

I don't know what you mean with "make does nothing" though. I would expect it to generate the redirects for the Python modules in the devel space or install the Python modules. Since include_package_data is not supported none of the files listed in the MANIFEST.in will be installed though.

@asmodehn
Copy link
Contributor Author

Sorry, I just mean make doesn't give any output.
But if i remove the devel/ space ( that has the python redirects indeed ), then make rerun the cmake process, and the python redirects are back into the devel/ folder.
So I guess everything is fine.

About include_package_data, I believe I can rewrite the same behavior via CMakeLists install rules when I patch for release, so it should not be a big problem, I think.

@dirk-thomas
Copy link
Member

Since this ticket was about supporting __file__ in setup file it was closed when the referenced PR was merged. If you consider to work on implementing support for include_package_data please consider creating a new ticket for it. It might also be good to write a short description how you plan to implement it in order to get some early feedback on the approach.

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

No branches or pull requests

2 participants