Using virtualenv with Komodo

Support Resolved
1

I’ve done a lot of searching online and can’t seem to find a definitive guide to using Komodo with python virtualenv, or pyenv for that matter. I have a desperate need to support a coworker. I use various techniques myself to avoid the virtualenv, but at this point, I can no longer avoid this pressing need.

Is there some sort of native support for virtualenv in 8.5.x? (I use the …4 nightlies, my colleague uses …3). Is there a tutorial I can use? I can find nothing in the help files, and little of use online.

If there isn’t native Komodo support in 8.5.x, is it finally supported out of the box in 9? I just downloaded the 9 alpha, and am looking forward to playing with it. I can’t tell my colleague to use alpha software in a production environment, however.

Please help. Lack of virtualenv support is a gaping hole in Komodo’s python support. Virtualenv is an essential ingredient in the python developer’s toolkit.

Thanks,
Wayne

2

Komodo supports VirtualEnv, in the sense that if you tell Komodo to use a Python virtualenv interpreter (via Komodo’s Python > Interpreter preferences) - it will work fine and provide completions/debugging support for that virtualenv. You can also set this preferences on a per-project level.

Komodo does not provide any UI to create/manage virtual environments.

Let us know if you need more information.

Cheers,
Todd

3

Thanks Todd, I got my coworker straightened out. One thing people might find useful is to add the virtualenv’s bin (or scripts in windows) to the front of the projects PATH env variable.

I am having some other issues re supporting virtualenv, though.

I maintain project templates, and often save the current project as a template. When I try to save templates that have the PATH env var and python interpreter pointing to a virtualenv instance of python, the values seem to disappear. That is, the path variable is no long in the projects environment, and the interpreter is set back to ‘find on path’.

Weird thing is that I’ve got another env variable set, and that one is indeed sticky. I’m using the 8.5.4 nightly.

Thanks,
Wayne

Edit: The one sticky environment variable is also set in the global preferences, so maybe it’s being inherited from there.

I’d like to be able to share projects that are pre-settup for various virtual envs, thus the need above, just to be clear.

Tested that this is indeed the same behavior as in 8.5.3

4

I tried recording a macro of changing the interpreter path as a starting point, but it failed to produce anything other than a set focus. Is it even possible to set project preferences from a macro?

Edit: Hmmm… rereading, I have been unclear. The settings don’t disappear from the project I am saving as a template, they are just absent from the saved template. Which makes it really hard to have templates for projects that include settings vital to using virtual environments.

5

It was a Komodo project cloning bug:

it’s been fixed and will flow into the Komodo 8.5.x niightlies on the next update.

Cheers,
Todd

6

Sweet! Thanks, Todd, you guys are the best.

7

Hi, @toddw!

I modified

C:\Program Files (x86)\ActiveState Komodo IDE 8
nightly\lib\mozilla\components\koProject.py

(from June 20th, the latest so far.)

520             part._path = self._path
521
522        if self == self._project:
523+            project.set_prefset(self.get_prefset().clone())
523-            self.set_prefset(self.get_prefset().clone())
524
525        a_names = self._attributes.keys()

Yet the behavior is unchanged. Environment and interpreter are not being saved/restored in/from project templates.

I have an additional concern… I looked at the .kpz file produced from make a template from project. Other than a .komodotools directory containing the projects tools, there is only a .kpf file. Inside of that .kpf file the only data is what appears to be a reference to the project that the template is created from.

That means that even if project preferences was working correctly that modifying the ‘parent’ project would modify the template! That’s really not a good idea! Additionally, sharing the .kpz files will not share the settings, unless the recipient somehow has a project with the same name (and/or id?) as the ‘parent’ project, with the same preferences.

Just as the tools are ‘frozen’ into the template via copying them, a reasonable set of preferences must be serialized from the ‘parent’ project into the template to make them at all useful as a way to share projects.

We already have import and export to share tools, sharing a project template has to do more than just that.

Thanks,
Wayne

8

The id and idref are recreated when creating a new project from a template - so that shouldn’t matter… and I believe these references are only relevant inside of a project - that don’t relate between projects.

Anyway, I can still reproduce this bug in the latest 8.5.x nightly and I’ve discovered why. This should have been:

part.set_prefset(self.get_prefset().clone())

The code is somewhat crufy and the project instance is not really used (not sure why it was written that way).

A re-fix coming in next nightly.

9

Hi, @toddw!

Thanks, I modded my nightly update from earlier today, and it’s working just fine now. The data is indeed stored in the .kpf file in the .kpz archive.

When I saw only the project ref, and no actual settings, I assumed that the settings were stored somewhere accessed by the project ref. But, that is not the case. Sorry for my misunderstanding, but I’m not familiar with komodo’s source and I was making assumptions from bugged output.

Thanks again, Todd.
Wayne

10

I’m glad it’s working correctly now - and thanks for following up on my first botched attempt to fix it :smile: