Hi Andrew and Fabio, I would like to add my two-cents on this topic. Echoing what Fabio said, I think that PyDev should not include a pre-configured Python (or other environment), however if redhat is providing pydev packages ready to use, it should include pydev configured for the python packages. (Same applies to other distributions, where possible.)
I think this should be an external plug-in to pydev, using the extensions available. One option is to fully configure the interpreter. Dawn has a similar use case where jython is packaged to allow scripting of the Dawn suite of tools. At Dawn we use: https://github.com/DawnScience/scisoft-ui/blob/master/uk.ac.diamond.scisoft/src/uk/ac/diamond/scisoft/JythonCreator.java to create a Jython Interpreter info automatically. I assume that froglogic's squish does something similar as it includes an Eclipse based IDE using PyDev and a Python build in its install tree and the Python is all configured in PyDev. Another option is to use/extend my recently contributed changes to PyDev to allow the "Auto" button to be extended. For example, the default implementation of Auto just searches for python, an improved version could look for python2 or python3.2 or whatever else is installed by the package manager. In this situation, a new plug-in that uses package info can contribute to PyDev's Auto by using org.python.pydev.pydev_interpreter_provider to provide a list of all installed Python's known. This new extension point has the option to run an install process too when selected, i.e. it could run yum or whatever to install python. I originally implemented this new feature to make it easier for scientists (who may have limited previous knowledge of installing/configuring Python) to get started with Dawn. It gives the option during Auto to install EPD Free's distribution of Python https://www.enthought.com/products/epd/free/. The advantage of EPD is that it is already preconfigured with all the packages the scientists are likely to need. See https://github.com/fabioz/Pydev/pull/38 for the pull request that added the feature. One final thought. I am about to do some work to make it easier to use cctbx python with PyDev (for Dawn again). cctbx has some extra settings that need to be set-up correctly. I haven't investigated this much yet, but I may extend the above mentioned extension point to allow further configuring of the interpreter info after creation. (The current extension point stops at providing an IInterpreterProvider which provides install option and path/name of installed python). There has also been some discussion of making Sage work with Dawn and PyDev, but I don't know how much demand there is for that yet. BTW Dawn's website in case you haven't come across it: http://www.dawnsci.org/ Much of the work I am currently doing for PyDev is funded by Diamond Light Source http://diamond.ac.uk/ to work on improving Dawn. Jonah On 1 August 2013 19:20, Fabio Zadrozny <fabi...@gmail.com> wrote: > Hi Andrew, > > Actually, it *should* be much better now than at that bug report: > > Right now, when PyDev is activated (i.e.: a Python editor is opened or > something that requires the interpreter), PyDev will already try to > auto-configure an interpreter, searching on different locations depending on > your platform. > > After doing that, it'll still ask the user to confirm if that's correct, > which I think is something good to have so that he can at least check we got > the correct interpreter. > > This happens at > org.python.pydev.ui.interpreters.AbstractInterpreterManager.ConfigureInterpreterJob > (you can test on a brand new workspace opening a .py file). > > So, I think the issue is mostly dealt with... > > What can still be done to improve the situation is that when the new project > wizard (which you're familiar with) is opened, if the user still has no > interpreter configured, we'll try to configure it automatically there too > (because right now, if he goes there without a configured interpreter, he > has to manually click the link to choose the interpreter and press > 'auto-config': this could be done for him as we know he'll have to click > that link before proceeding because he has no interpreter configured -- you > can check ConfigureInterpreterJob as a reference for how to do that). > > Cheers, > > Fabio > > > On Thu, Aug 1, 2013 at 2:38 PM, Andrew Ferrazzutti <aferr...@redhat.com> > wrote: >> >> Hi Fabio, >> >> Alex recently assigned me to the bug where PyDev doesn't come a >> pre-configured Python environment. Considering this bug was reported six >> years ago, I'm assuming there's some reason why it hasn't been addressed. Is >> there a certain way you wanted this to be fixed? Alex suggested using an >> extension point to automatically search for /usr/bin/python or somewhere >> similar for a usable binary. If there's some other method you'd rather use >> I'm all ears. >> >> Andrew > > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > pydev-code mailing list > pydev-code@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pydev-code > ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ pydev-code mailing list pydev-code@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pydev-code
