Feature request - play nicely with other plugins

[posita]

It appears that autocomplete-plus-python-jedi runs jedi-cmd.py at the time a new window is created and it persists (with whatever environment it got at that point) until that window is closed, whereas the virtualenv Atom package allows for later context switching at the window level. This context switch is completely missed by autocomplete-plus-python-jedi.

It would be nice if there was some mechanism by which autocomplete-plus-python-jedi could restart the jedi-cmd.py under the new environment when it detects one. This may require coordination between the two projects. I have filed a sister issue (tinloaf/autocomplete-plus-python-jedi#12) to track this.

[mattdeboard]

I think getting specific packages to play nicely with each other is the wrong approach.

@jhutchins is doing it right by emitting events. It think it might be very useful if emissions like this one were changed to be like:

@emit('virtualenv:changed', @env, @path)

However I know absolutely nothing about whether those events "bubble up" to be available to other packages. But assuming they are available, then could use something like event-kit or whatever to handle that event AND the args it sends to do the needful wrt virtualenv:

class JediProvider
  # ...
  onVirtualenvChanged: (virtualenvName, virtualenvPath) ->
    @proc.kill()
    delete @proc # dunno if this is necessary
    command = "#{virtualenvPath}/bin/python"
    @proc = spawn(command, [ __dirname + '/jedi-cmd.py', projectPath ])
    # ...whatever other setup for the new process has to happen ...

Ok obviously I am just making things up at this point but hopefully i've made it clear what I'm thinking.

[posita]

@mattdeboard, thanks for that. 👍 I had not researched this package thoroughly enough to be aware of its existing event emission. 😞 It might interest you to know that I was (crudely) converging on something similar to your more-informed suggestion (see this tinloaf/autocomplete-plus-python-jedi#12 (comment)).

[tinloaf]

So... as long as the events do not contain the path / environment, is there any other way for some other package to get a path to the currently activated environment? It would be easy to just reload that every time the 'virtualenv:canged' event is received...