Add pew style project management to peotry

[sametmax]

• [ X] I have searched the issues of this repo and believe that this is not a duplicate.

Issue

pew, an alternative way to manage virtualenv, has a "project" feature. You give a name to a virtualenv (pew new venv_name), then tie this name to the directory (pew setproject .). You can then activate the virtualenv from anywhere doing pew workon venv_name. It will activate the venv whether you are in the project dir or not. If you are not in the project dir, it will cd you to the project dir. It will do so even if the virtualenv is already activated.

Poetry doesn't work by virtualenv name though, so the feature would need a tweak. We could imagine it as a alias, with an API like:

$ poetry alias name src_dir # give a name to the directory / virtualenv pair
$ poetry aliases # list all name + src directory + venv dir
$ poetry go name  # activate venv and cd to the src dir 
$ poetry rmaliase name # remove the alias
$ poetry init # also prompt for the project alias name

Because poetry init already asks for a package name, it can offer to use this name as an alias by default, provided it's not already used elsewhere (which will happen if you have several versions of the same code lying around). Of course the user is free to type in whatever he or she wants, and should be able to disable the automatic cd.

This does require a persistent setting file in the user directory to list all aliases (is it ok to put it in config.toml ?), and some error handling for the case where an alias reference a missing project.

[brycedrennan]

I'm not familiar with pew. Is the value-add here is that poetry would remember where a project is so that developers can quickly cd to it?

[sametmax]

cd + activate the venv in a short cmd, yes. Le 09/08/2019 à 16:27, Bryce Drennan a écrit :

…

I'm not familiar with pew. Is the value-add here is that poetry would remember where a project is so that developers can quickly |cd| to it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#704>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMYVXR7NSY7C6TID4ZYZ73QDV5F7ANCNFSM4GIVVOHQ>.

[sdispater]

I think this goes beyond the purpose of Poetry. However, once the plugin system (see #1237) is ready that might be a good fit for it.

[zvolsky]

In fact this is a single reason why I need virtualenvwrapper together with poetry.
This makes me problems with use of non-poetry virtualenv (virtualenvwrapper creates venvs in ~/.virtualenvs) and I sure would prefer the poetry way of venvs management because here is good integration with pyenv.
However the workon <project> is too worth for me. So I still use the old style venvs :(

So it would be really nice to have poetry workon ... (or poetry go ... as proposed here).
I think the idea of alias presented here could be good.
But it should be a little more analyzed how it could integrate with poetry/pyenv possibility to have 2+ venvs for 1 project but for 2+ different python versions.

[yggi49]

I think this goes beyond the purpose of Poetry. However, once the plugin system (see #1237) is ready that might be a good fit for it.

I just made a first attempt at that. If you are interested, check out poetry-alias—feedback appreciated.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.