py-spyder can't find pylint and ipython out of the box

[mbrethen@…]

Versions of pylint should probably use the select portgroup like the python_select port does. Ports such as py26-spyder look for pylint in the user's system path (e.g. /opt/local/bin).

[mbrethen@…]

Reference Ticket #30446: 'Add py27-spyder port'

[jmroot (Joshua Root)]

This is not a solution to the problem. What if you have py27-lint selected and also want to install py26-spyder? The spyder ports either need to be patched to use pylint-X.Y, or to add ${python.prefix}/bin to their PATH.

[mbrethen@…]

If you install py26-spyder, you may be surprised to find that you can't analyze your python code because it can't find a pylint binary in your system path.

I had the same issue with ipython until I used 'port select'. Why do some modules have a default (ipython) and others do not? Unless you have a very good reason for not doing so, MacPorts should be consistent in the way it interacts with a developer's software.

[mbrethen@…]

I thought I should expound on my last comment. Spyder had the same problem with ipython; in fact it would not even start after I installed the ipython port. IPython_select exists and so I issued a 'port select ipython ipython27' before Spyder would run correctly.

[jmroot (Joshua Root)]

The approach is consistent. Any port that doesn't work until you port select something is broken. I mentioned two possible fixes in comment:2.

[mbrethen@…]

My main point is that the py26-spyder port is broken, neither ipython nor pylint work with spyder out-of-box, so to speak. It was a simple matter to run ipython_select to fix it, whereas I spent a couple weeks discussing pylint with MacPorts and the Spyder developers. The reason it's broken is due to differences bewteen the python environment on linux/windows versus MacPorts' python framework.

[sewebster@…]

Cc Me!

[sewebster@…]

Isn't this a good example of where macports can patch the port in question (spyder) to make it work in our environment?

[mbrethen@…]

If the intent is to have spyder run within a python framework, then I would say it's utter failure. Spyder's developer expects to find default python binaries in the user's path. The existing port, py26-spyder has no such patches and when installed will use whatever un-suffixed python binary (along with all the modules) it can find in PATH. If it does not find one, pylint for example, you get a message in spyder to install it.

As such, py26-spyder, py27-spyder, etc. seem irrelevant. It makes more sense (to me anyway) to have a single port of spyder with a default python (using the port select function). Otherwise have fun sifting through all the python scripts trying figure out which ones to patch.

[mbrethen@…]

I must retract my last comment with an apology. It seems that the spyder.app is compiled with the correct python launcher, so it does run in the proper framework. However, the 'programs.py' script is where module existence is checked by spyder. There are 2 functions: 'is_program_installed' and 'is_module_installed'. The former uses PATH to find the binary, which will fail under the MacPorts python framework. The latter tries to import the module, which should work within the same framework that spyder is installed. According to the developer, the 'current implementation of pylint plugin call pylint in a separate process.'

[ryandesign (Ryan Carsten Schmidt)]

Is this still a problem with the current py-pylint port?

[petrrr]

Cc Me!

[petrrr]

Cc Me!

[eborisch (Eric A. Borisch)]

Closing out this old ticket; spyder should be detecting these correctly now.