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

Unresolved reference 'snakemake' #511

Closed
iquasere opened this issue Jan 26, 2024 · 5 comments
Closed

Unresolved reference 'snakemake' #511

iquasere opened this issue Jan 26, 2024 · 5 comments

Comments

@iquasere
Copy link

I never got, on my MacBook Pro M2, snakemake recognized. Is this working as designed? The pipeline runs fine.

image

SnakeCharm version: 2023.2.1

@iromeo
Copy link
Contributor

iromeo commented Apr 4, 2024

Hi, as a workaround, you could add manually import snakemake line, it will not affect pipeline, but will help with static code analysis. Snakemake executes a snakemake file in a special environment, where some objects are inserted dynamically, so snakemake module will be available on runtime, but SnakeCharm codeInsight engine doesn't emulates this at the moment.

@iromeo
Copy link
Contributor

iromeo commented Apr 30, 2024

@iquasere Is it *.smk or Snakefile or just some *.py file with wrapper impl?

@iquasere
Copy link
Author

iquasere commented May 7, 2024

Thank you for the answer, @iromeo !

This is happening only for the *.py scripts, although the *.smk files have another problem, where it doesn't recognize stuff coming from the common.smk script.

image

Still, the most annoying is in the *.py files.

Hi, as a workaround, you could add manually import snakemake line

This turned all the errors into warnings, which is better. I guess it wouldn't make sense to have a params attribute in snakemake's __init__

image

@iromeo
Copy link
Contributor

iromeo commented Oct 21, 2024

@iquasere

where it doesn't recognize stuff coming from the common.smk script.

Thx for mentioning that, it is known problem #364. Snakemake files don't follow Python conventions on how code from different modules is imported. Instead snakemake framework assemble a context depending on the Snakefile content. So if you run you Snakefile that first includes common.smk, then some foo.smk, all content from common.smk will be available in foo.smk. But if you specify foo.smk as enty point, then common.smk will not be avaiable. Snakecharm plugin should definitely emulate such logic to avoid such false alerts.

*.py scripts,

The similar case for *.py scripts used inside snakemake. From python point such scripts doesn't work independently as valid python files. Again we need to somehow differentiate python files that could have such usage from other files where snakefile will be indeed unresolved.


You could always disable some false alerts using 'suppress' action for any inspection.

image image

as alternative, you could add identifiers (e.g. OUTPUT) for which unresolved reference will not be shown in 'Unresolved references' inspections settings:

image

iromeo added a commit that referenced this issue Oct 22, 2024
@iromeo
Copy link
Contributor

iromeo commented Oct 22, 2024

I added workaround, so unresolved snakemake runtime-injected variable will not be shown as error here, e.g.:

image image

@iromeo iromeo closed this as completed Oct 22, 2024
@iromeo iromeo modified the milestones: next release, 2024.2.2 Oct 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants