Pipenv: Is it possible to list which virtualenvs are managed by pipenv?

[pfmoore]

In my ~/.virtualenvs folder, I have a number of environments - some are managed by pew and others by pipenv. I can't easily tell which is which (although my guess is that the ones ending in -<random letters> are managed by pipenv), nor do I appear to be able to identify which project directory is associated with the pipenv-managed venvs.

Basically, I'm looking for a way to do housekeeping on old or experimental projects - identify and tidy up no longer used virtual environments, determine whether it's OK to delete a project directory or if it will leave a venv behind, etc. My ~ directory is on a limited-space SSD, so I'd prefer to keep it clean.

[techalchemy]

Hey @pfmoore this is an idea we’ve kicked around a bit in the past but I believe we decided against. We’ve been primarily cutting down on features to focus on the basics lately

Given the use case this may be worth revisiting. @kennethreitz will have to weigh in

[pfmoore]

Hi @techalchemy thanks for the information.

Looking at the code, it seems that the env name is based on a hash of the full pathname of the project. So it's not reversible - which means the only way to make that link would be by adding a pointer back to the project directory from the venv. That's a shame :-(

Also, that algorithm means that there's a potential issue - I hesitate to describe it as an out and out bug, but I'd be interested in what you think - on case-insensitive filesystems, where changing the case of the project directory name would break the link to the venv, even though logically the directory is the same. Certainly I normalise the case of directories on occasion, so it's not completely out of the question that this happens. I know that the venv is "throwaway" in the sense that a quick pipenv install should rebuild it, but again it has the potential to leave unwanted venvs behind. In my experience, Windows users in particular would expect to be able to change the case of a directory name without it mattering, so while it's not technically an OS-dependent issue, it probably does relate to user expectations on different operating systems...

[techalchemy]

@pfmoore two points of response:

the only way to make that link would be by adding a pointer back to the project directory from the venv

That would be the only solution to this particular problem, agreed. I believe that is what pew setproject does which was one consideration for implementation of this, the other was to just set a PROJECT_HOME variable or something like that and hash paths there to check for virtualenvs. The alternative would be to write some pipenv-specific file. I think both of these are pretty equally fine, possibly the second option is preferable. Thoughts?

on case-insensitive filesystems, where changing the case of the project directory name would break the link to the venv, even though logically the directory is the same

We did run into this early on, but we normalize the case now before we do virtualenv lookups. In particular, for backwards compatibility, we have our own implementation of drive case normalization for windows to avoid rebuilding existing virtualenvs -- I _would_ describe it as a bug in its original implementation though

[pfmoore]

We did run into this early on, but we normalize the case now

Hmm, I checked this and changing the case of my directory did lose the link to the venv. Maybe I did something wrong, or I have an older version of pipenv? I can't retest right now as I'm on a different PC, but I'll try to check again. Either way, if it is behaving wrongly, that would be a separate issue so I'll report it as such if needed. Thanks.

[jtratner]

Aside - Can you use PIPENV_VENV_IN_PROJECT? it causes pipenv to put the
venv in the current directory (as .venv) rather than in a separate
directory.
On Thu, Mar 22, 2018 at 10:34 AM Paul Moore [e-mail]
wrote:

We did run into this early on, but we normalize the case now

Hmm, I checked this and changing the case of my directory did lose the
link to the venv. Maybe I did something wrong, or I have an older version
of pipenv? I can't retest right now as I'm on a different PC, but I'll try
to check again. Either way, if it is behaving wrongly, that would be a
separate issue so I'll report it as such if needed. Thanks.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/1824#issuecomment-375393288, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjq47aQue24b3doqkgqlVO_nxeBB24ks5tg-CIgaJpZM4S2ve1
.

[pfmoore]

@jtratner Thanks - I didn't know about that option. It might be a better way of working for me[1] - I'll look into it. Is there a way of setting it in a global config file, rather than as an environment variable? I couldn't see anything in the docs, so I'm guessing maybe there isn't? (Settings files are more common practice on Windows than environment variables for persistent configuration).

[1] To compensate for my disorganised workflow :-)

[techalchemy]

@pfmoore I know many people (including Nate) keep it set -- but yeah it is only available as an environment variable right now (unfortunately). We don't have any plans for global config at the moment but obviously with enough demand we could move in that direction.

However, if you have a .venv folder in your project pipenv will find it automatically so that may offer some convenience.

Hmm, I checked this and changing the case of my directory did lose the link to the venv. Maybe I did something wrong, or I have an older version of pipenv?

I _think_ we meant to fix that behavior, although we may not have planned for users re-casing their own folders (/cc @uranusjr) -- we would have to plan for this on windows specifically right? Because that's the only OS (that we support, afaik) where the filesystem is an API and a lowercase vs uppercase path are technically the same location -- correct me if I'm wrong on that. I don't think it's an issue to code around it

[pfmoore]

I'm not quite sure what you mean by "the filesystem is an API" but case sensitivity is a filesystem thing, not so much an OS thing (consider SAMBA or FAT32 on Linux). But either way, it's a minor point, it's not likely to affect many people, or affect them significantly.

[techalchemy]

I just meant that it is only exposed that way for interaction but valid point re: samba etc. I'm not that familiar with the implementation details so I'm basically just hand-waving here

[uranusjr]

I was informed on Twitter about Pipes that does this. I didn’t dig into the details, but from the README it does this with a project file like Pew. You might want to look into it; I’m sure the author would love some feedback and traction :D

Closing this so attention can be more focused on Pipes, at least for now.

[techalchemy]

Whoa that is super cool.

[pfmoore]

Um, that's a very new project, and from a quick look (https://github.com/gtalarico/pipenv-pipes/blob/master/pipenv_pipes/environment.py#L8) it doesn't seem to support Windows (yet?). So while in the longer term it may be useful, it's not really something I want to rely on right now.

Also, I still think this is a capability that should be in core pipenv.

[techalchemy]

I actually lean toward this myself @pfmoore and while the project does look cool the concerns are definitely valid. Also, implementation isn't that challenging IMO

[meshy]

In that spirit, would it be ok to re-open #1861?

[erinxocon]

I would agree that pipes is a bit premature to be included. I've reopened that PR. @meshy if you could pull and rebase so we can test that would be great!

[techalchemy]

To be clear we should start there and then reopen the conversation with Kenneth about his views on the api changes that would be involved. I've discussed it with him before and we've both kind of vacillated, I know I went as far as a full implementation before deciding it was probably a lot of work to maintain

[uranusjr]

This is made better now that #1861 is merged, and Pipes seems to be coming along quite nicely. We might still want to have a pipenv --list to do this though.

[kennethreitz42]

pipes is the solution.

[GreatBahram]

@kennethreitz what do I have to do to list all my virtual environment that works with pipenv?