Issues

Issue #120 resolved

Conflict of .project description file from Eclipse and the .project from the virtualenvwrapper.sh

Arthur Alvim
created an issue

When trying to work with virtualenvwrapper with Eclipse it gets showing (cat) the code inside .project description file generated by Eclipse everytime I use the command workon. I've tried changing the name .project to something else in virtualenvwrapper.sh but it didn't work. Althought, when I renamed the file .project to something else, the command workon work properly (it didnt show any code) but I was unable to work with Eclipse. It has been seen that the conflict is in the .project file.

Comments (9)

  1. Doug Hellmann repo owner
    • changed status to open

    I guess both tools are guilty of choosing a bad name for that file.

    The venvw project file should be going into the root of the virtualenv. Can you put the eclipse project file in a "src" subdirectory or something like that?

  2. Arthur Alvim reporter

    I was trying to work with the $WORKON_HOME as my Eclipse workspace. So each virtualenv project would be recognized as a Eclipse project easily. Its working like that now. The only inconvenience is that when I'm in terminal and used the workon command it keeps showing the .project code. I agree with you about the bad naming. I would recommend changing the .project to something different like .venvw_project, but since I'm the only one complaining about this, I will do what you suggested, put everything inside a folder. But I'd like to know if there's other places where you use the .project file. In the virtualenvwrapper.sh it appears 4 times. I've tried to change them but it didn't work and kept showing the .project code.

    I really like your project and would appreciate to see virtualenv+virtualenvwrapper working together with some nice IDE, such as Eclipse. Would recommend any other IDE?

  3. Doug Hellmann repo owner

    The project file is used by the postactivate hook of the project plugin to determine the "project directory" associated with a virtualenv. Usually those are different from the virtualenv itself, since you may want to delete and recreate the virtualenv without losing the local copy of your code. So the cat output is coming from the post_activate_source() function in project.py.

    If you set PROJECT_HOME and WORKON_HOME to different directories, and put your source in the directories in PROJECT_HOME, I think you will get the effect you want. You can have an Eclipse .project file in $PROJECT_HOME/foo and venvw can keep its .project files in $WORKON_HOME/foo.

  4. Anonymous

    Just came across this thread looking for a solution to the exact same problem. With all due respect, the solution given reeks of "ugly hack around ugly programming".

    The natural/logical way to use virtualenv is the way that Arthur, myself, and any other Eclipse user would do it: one virtualenv per workspace. Users of both tools should not have to re-arrange their filesystem just because two different developers both like the sound of ".project" (and since Eclipse has been using ".project" for years, I think they should get dibs on the name).

    Could you please re-consider your decision, and either: A) rename ".project" to ".virtualenvproject"?, or B) provide some sort of configuration option for virtualenv that let's you tell it to use ".virtualenvproject"?

    Forcing all of your users to re-arrange their filesystem in order to use your tool is just wrong.

  5. Anonymous

    Didn't realize I was anon; my name is Jeremy, if that makes you feel any better. And while I guess "pissy" is a subjective assessment, I was being sincere: forcing your users to re-arrange their file system just to use your tool (and another tool which is wayyyy more popular) is a pretty lame way to go.

  6. Anonymous

    (Of course, as an OSS developer it's absolutely your prerogative to do whatever you want with your tool, without any consideration for your end users and their needs; if you can't be bothered to change a file name, and they want a tool that works with Eclipse, they can always fork right? So feel free to ignore anonymous "pissy" comments from people like myself ... unless you're actually trying to make your tool better for other people, in which case maybe you shouldn't dismiss a comment just because it's not what you want to hear.)

  7. Anonymous

    Another thought: instead of changing the filename, you could simply add a check to the .project loader so that if it sees .project is an Eclipse file, it doesn't try to load it. Something like:

    if (loadedFilesContents.indexOf("<projectDescription>") != -1) dontLoadFile();

    should do the trick, without any renaming required.

  8. Log in to comment