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

VS code debugger doesn't load /opt/continuum/project into sys.path #24

Open
saraneem opened this issue Aug 19, 2020 · 5 comments
Open

Comments

@saraneem
Copy link

From European Investment Bank:

When we try to use the vs code debugger for a file located in a subfolder, /opt/continuum/project isn't loaded into sys.path. This means that the local import doesn't work.

Here is a concrete example:

In /opt/continuum/project I create a file test.py and I create a function 'func' in it.
Then I create a folder, with an init.py file and another file 'test2.py'. If I try to import "from test import func", it will fail if I try to debug the file.

It works well if we use conda develop /opt/continuum/project but this configuration can't be saved.

ZD ticket: https://anaconda.zendesk.com/agent/tickets/21015

@AlbertDeFusco
Copy link
Collaborator

I'll take a look.

@AlbertDeFusco
Copy link
Collaborator

I'm looking at the PNG from the zendesk ticket and this what I see

project/
├── __init__.py
├── anaconda-project.yml
├── folder/
│   ├── __init__.py
│   └── second.py
└── test.py
# folder/second.py

from test import func

The folder/second.py file attempts to import from a file in the main project directory called test.py, but that is not allowed. Please note that the same error message occurs on desktop VSCode.

@mcg1969 , @philippjfr , @jlstevens , I'm inclined to say that this is not a supported use case of Python imports and a different directory structure should be adopted. I'm also not inclined to have ae5-vscode or the session extension adjust sys.path or $PYTHONPATH. Are any of you more aware of what they're attempting to do?

@mcg1969
Copy link
Collaborator

mcg1969 commented Aug 24, 2020

I agree with your analysis and verdict far as we understand it. I don't know more about the use case.

@philippjfr
Copy link

philippjfr commented Aug 24, 2020

I agree with that assessment too. I've never tried it but is it possible to ship a package inside an anaconda project with a setup.py and then install it (equivalent to pip install -e .)? I'm guessing at their use case here but I think that would address their needs but even if it worked that would be kind of a pain to set up for a novice.

@jlstevens
Copy link
Collaborator

I've never tried it but is it possible to ship a package inside an anaconda project with a setup.py and then install it (equivalent to pip install -e .)

Even if that actually works, I would consider it a flaming hack! Dependencies should be installed as part of prepare and not installed ad hoc in this way. On the other hand, I wonder if it is hack that would work well enough for EIB that we can tell them about even if we don't like it/endorse it.

I agree with @mcg1969 that we need to know more about the use case before suggesting anything.

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

5 participants