Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support virtualenvwrappers .project file #133

Closed
dwt opened this issue Dec 1, 2017 · 4 comments
Closed

support virtualenvwrappers .project file #133

dwt opened this issue Dec 1, 2017 · 4 comments

Comments

@dwt
Copy link
Contributor

dwt commented Dec 1, 2017

It's a file in the virtualenv called '.project' that contains a path to the folder that should be changed too when activating the virtualenv.

As far as I can see from my experiments and the documentation this is not yet supported, but super useful as not all of my projects are in one folder, thus (at least seemingly) making the projects plugin not working for me.

@justinmayer
Copy link
Owner

Hi Martin. I am the original author of the Projects plugin, and I originally tried to support .project files, as you can see in the extended discussion in the original pull request: #22

In short, I found that trying to support .project files made the implementation overly complicated. Moreover, since I always keep projects in a single directory, I am not inclined to revisit that endeavor myself.

Last but not least, since there is growing momentum behind Pipenv as the go-to solution for project/dependency/virtualenv management, the Projects plugin's approach will likely need to be revisited in the months to come. My guess is that .project files will be unnecessary in a Pipenv context.

@dwt
Copy link
Contributor Author

dwt commented Dec 1, 2017

Well, do you mind me adding a pull request to support .project files? Because they are quite essential to me and my workflow. Just to illustrate:

My project folder is organized mostly like this:
$customer/$project - but also partly by $topic/$project. This I would really like not to change because of a tool change. Also because pipenv and virtualenvwrapper already work together really nicely, so I don't really see a reason why this should obsolete the .project approach from virtualenvwrapper.

Could you advise where this would have to go in the source code? (I haven't written fish before)

@justinmayer
Copy link
Owner

I hear you, and I understand your perspective. Unfortunately, due to stringent time constraints at the moment, this isn't something I will be able to assist with. Please accept my apologies.

@justinmayer
Copy link
Owner

Preliminary support for .project files has been added via #149.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants