Intellisense Support for Airflow Plugins in VSCode - visual-studio-code

I'm trying to find a way to make VSCode Python intellisense work with Airflow Plugins.
Following the code example the import path of plugin operators could be:
from airflow.operators import MyPluginOperator
VSCode cannot resolve this import because it will only be valid at runtime through the airflow plugin system.
Is there any way to configure VSCode to resolve this import?

Airflow loads plugins dynamically by searching the airflow/plugins folder for AirflowPlugin subclasses and add them in airflow namespace in a runtime. Here is the code from airflow/operators/__init__.py:
# Imports operators dynamically while keeping the package API clean,
# abstracting the underlying modules
...
def _integrate_plugins():
"""Integrate plugins to the context"""
from airflow.plugins_manager import operators_modules
for operators_module in operators_modules:
sys.modules[operators_module.__name__] = operators_module
globals()[operators_module._name] = operators_module
VS Code can't handle it. Even "big" Python IDEs like PyCharm has problems with it. It is impossible for VS Code to know that a piece of code in particular folder will transform in airflow.operator later. "python.autoComplete.extraPaths" will not help too. You should only hope that someone will write a VS Code extension for Airflow somewhere :)

Since version 2.0.0 the way that Airflow handles plugins imports has changed:
Importing operators, sensors, hooks added in plugins via airflow.{operators,sensors,hooks}.<plugin_name> is no longer supported, and these extensions should just be imported as regular python modules. For more information, see: Modules Management and Creating a custom Operator
The next important thing to consider is that Airflow adds dags/, plugins/, and config/ directories to PYTHONPATH env. source
Following the specifications from the docs, you could create your MyCustomOperator
in airflow_home/plugins/custom_operator/ directory. Then you could use it like this:
from custom_operator.my_custom_operator import MyCustomOperator
with dag:
sample_custom_task = MyCustomOperator(task_id='sample-task')
So far so good, the dag will run, but according to my experience, the VSCode IntelliSense won't work yet. To make it work, you need to add the path to /plugins as same as Airflow will do when it runs. Depending on your setup there are a few ways to do this. The goal is to add an extra path to the python interpreter VSCode is "using" (make sure to select the interpreter related to your project)
A common solution could be to use the env PYTHONPATH to append our path to the path the interpreter knows. In my case, I'm using a virtual environment, so following the explained in this post, I created a .pth file with the path I wanted to add and locate that file on airflow_home/venv/lib/my_python_version/site-packages/
Following the path on our example, this will create such a file:
cd $(python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")
echo airflow_home/plugins > airflow_plugins_example.pth
Once that is done, reload VSCode (could also just change to another interpreter and then come back) and you should see the intelliSense working properly.
Hope that works!

Related

VSCode: how to structure a simple python package with few modules and tests, debugging and linting?

I'm having more trouble than I'd like to admit to structure a simple project in Python to develop using Visual Studio Code.
How should I structure in my file system a project that is a simple Python package with a few modules? Just a bunch of *.py files together. My requisites are:
I must be able to step debug it in vscode.
It has a bunch of unit tests using pytest.
I can select to debug a specific test from vscode tab and it must stop in breakpoints.
pylint must not show any false positives.
The test files must be in a different directory of the main module files.
I must be able to run all the tests from the console.
The module is executed inside a virtual environment using python standard lib module venv
The code will use type hints
I may use another linter, even another test framework.
Nothing fancy, but I'm really having trouble to get it right. I want to know:
How should I organize my subdirectory: a folder with the main files and a sibling folder with the tests? Or a subfolder with the code and a subsubfolder with the tests?
Which dirs must have a init.py file?
How the tests should import the files from the module? Should I use relative imports?
Should I create a pytest.ini file?
Should I create a .env file?
What's the content of my launch.json the debugger file config in vscode?
Common dir structure:
app
__init__.py
yourappcode.py
tests (pytest looks for this)
__init__.py
test_yourunittests.py
server.py if you have one
.env
.coveragerc
README.md
Pipfile
.gitignore
pyproject.toml if you want
.vscode (helpful)
launch.json
settings.json
Or you could do one better. Ignore my structure and look at the some of famous python projects github page. Like fastAPI, Flask, asgi, aiohttp are some that I can think of right now
Also:
I think absolute imports are easier to work with compared to relative imports, I could be wrong though
vscode is able to use pytest. Make sure you have a testing extension. Vscode has a built in one im pretty sure. You can configure it to pytest and specify your test dir. You can also run your test from command line. If youre at the root, just running ‘pytest’ will recognise your tests dir if it’s named that by default. Also your actual test files need to start with prefix test_ i think.
The launch.json doesn’t need to be anything special. When you click on the settings button next to play button in the debug panel. Vscode will ask what kind of app is it. I.e If its a flask app, select python then select flask and it will auto generate a settings file which you can tweak however you want in order to get your app to run. I.e maybe you want to expose a different port or the commands to run your app are different
It sounds to me like you just need to spend a bit of time configuring vscode to your specific python needs. For example, you can use a virtualenv and linting in whichever way you want. You just need to have a settings.json file in the .vscode folder in your repo where you specify your settings. Configurations to specify python virtualenv and linting methods can be found online

How to create python libraries and how to import it in palantir foundry

In order to generalize the python functions, I wanted to add functions to python libraries so that I can use these function across the multiple repositories. Anyone please answer the below questions.
1) How to create our own python libraries
2) how to import those libraries across multiple repositories
How to create python libraries in Palantir Foundry?
To create a new library, you can do so by creating a new repository. When prompted to initialise the repository, you should have an option that reads:
Python Library
Template for publishing a Python library package. Consuming new libraries has changed,
please read README in library repository.
The readme will contain instructions on how to publish a library. It is recommended you understand how conda publishing channels work for this.
A note, avoid using _ in the library name, since it can cause problems. - is safe to use though.
How to import a library in code authoring?
Once your library is publishing, you can add it to your conda recipe of the repository you want to consume the library in. You can find this in: transforms-python/conda_recipe/meta.yaml
Afterwards just add it to the list of under
requirements:
run:
- python
- pandas
- your-library-name
In addition to fmsf's answer, in the second step you might have to add the following content to the build.gradle of your transforms-python directory:
transformsPython {
sharedChannels "libs"
}

Ember cli - use sass addon in less project

I use broccoli-less in my ember cli project and would like to use an addon (ember-cli-materialize), which uses broccoli-sass.
After installing the addon, i get: File to read not found or unreadable ../app.scss, because i also have an app.less file in my styles dir.
As i understand, this commit Allow multiple preprocessors per type should make it possible, although i might be missing something. Has anyone managed to use ember-cli with multiple preprocessors, and what changes is needed?
Ember-cli version: 1.13.1
Ember version: 1.12.0
Thanks
I know your circumstance is different than mine but this may help others or spur a better solution. I was added to a dev team to polish up an app already styled using LESS. I favor SASS and tried to use ember-cli-sass alongside ember-cli-less without any success.
You may want to look further into Ember-Cli's add.import
By adding your input configurations to ember-cli-build.js with the above, you can leverage either your bower-components directory (if used) or vendor directory, to import a compiled CSS doc (from Sass source files) that will build alongside the project quite nicely with a simple sass --watch <input:output> command.
The LESS files are ultimately compiled to app.css, and your SASS files to vendor.css (make sure you link to the stylesheet in your index page/template).

PyCharm - automatically set environment variables

I'm using virtualenv, virtualenvwrapper and PyCharm.
I have a postactivate script that runs an "export" command to apply the environment variables needed for each project, so when I run "workon X", the variables are ready for me.
However, when working with PyCharm I can't seem to get it to use those variables by running the postactivate file (in the "before launch" setting). I have to manually enter each environment variable in the Run/Debug configuration window.
Is there any way to automatically set environment variables within PyCharm? Or do I have to do this manually for every new project and variable change?
I was looking for a way to do this today and stumbled across another variation of the same question (linked below) and left my solution there although it seems to be useful for this question as well. They're handling loading the environment variables in the code itself.
Given that this is mainly a problem while in development, I prefer this approach:
Open a terminal
Assuming virtualenvwrapper is being used, activate the virtualenv of the project which will cause the hooks to run and set the environment variables (assuming you're setting them in, say, the postactivate hook)
Launch PyCharm from this command line.
Pycharm will then have access to the environment variables. Likely because of something having to do with the PyCharm process being a child of the shell.
https://stackoverflow.com/a/30374246/4924748
I have same problem.
Trying to maintain environment variables through UI is a tedious job.
It seems pycharm only load env variables through bash_profile once when it startup.
After that, any export or trying to run a before job to change bash_profile is useless
wondering when will pycharm team improve this
In my case, my workaround for remote interpreter works better than local,
since I can modify /etc/environment and reboot the vm
for local interpreter, the best solution I can do are these:
1. Create a template Run/Debug config template and clone it
If your env variables are stable, this is a simple solution for creating diff config with same env variables without re-typing them.
create the template config, enter the env variables you need.
clone them
see picture
2. Change your script
Maybe add some code by using os.environ[] = value at your main script
but I don't want to do this, it change my product code and might be accidentally committed
Hope someone could give better answer, I've been spent too much time on this issue...
Another hack solution, but a straightforward one that, for my purposes, suffices. Note that while this is particular to Ubuntu (and presumably Mint) linux, there might be something of use for Mac as well.
What I do is add a line to the launch script (pycharm.sh) that sources the needed environment variables (in my case I was running into problems w/ cx_Oracle in Pycharm that weren't otherwise affecting scripts run at command line). If you keep environment variables in a file called, for example, .env_local that's in your home directory, you can add the following line to pycharm.sh:
. $HOME/.env_local
Two important things to note here with respect to why I specifically use '.' (rather than 'source') and why I use '$HOME' rather than '~', which in bash are effectively interchangeable. 1) I noticed that pycharm.sh uses the #!/bin/sh, and I realized that in Ubuntu, sh now points to dash (rather than bash). 2) dash, as it turns out, doesn't have the source "builtin", nor will ~ resolve to your home dir.
I also realize that every time I upgrade PyCharm, I'll have to modify the pycharm.sh file, so this isn't ideal. Still beats having to manage the run configurations! Hope it helps.
OK, I found better workaround!
1.install fabric in your virtualenv
go to terminal and
1. workon your virtualenv name
2. pip install fabric
2. add fabric.py
add a python file and named it "fabric.py" under your project root, past the code below,and change the path variables to your own
from fabric.api import *
import os
path_to_your_export_script = '/Users/freddyTan/workspace/test.sh'
# here is where you put your virtualenvwrapper environment export script
# could be .bash_profile or .bashrc depend on how you setup your vertualenvwrapper
path_to_your_bash_file = '/Users/freddyTan/.bash_profile'
def run_python(py_path, virtualenv_path):
# get virtualenv folder, parent of bin
virtualenv_path = os.path.dirname(virtualenv_path)
# get virtualenv name
virtualenv_name = os.path.basename(virtualenv_path)
with hide('running'), settings(warn_only=True):
with prefix('source %s' % path_to_your_export_script):
with prefix('source %s' % path_to_your_bash_file):
with prefix('workon %s' % virtualenv_name):
local('python %s' % py_path)
3. add a external tool
go to
preference-> External tools -> click add button
and fill in following info
Name: whatever
Group: whatever
Program: "path to your virtualenv, should be under '$HOME/.virtualenvs' by default"/bin/fab
Parameter: run_python:py_path=$FilePath$,virtualenv_path=$PyInterpreterDirectory$
Working directory: $ProjectFileDir$
screenshot
wolla, run it
go to your main.py, right click, find the external name (ex. "whatever"), and click it
you could also add shortcut for this external tool
screenshot
drawbacks
this only work on python 2.x, because fabric don't support python 3

Relative import from parent directory

How does one do a relative import from a parent directory?
From meme/cmd/meme:
import "../../../meme"
This gives an ambiguous error:
matt#stanley:~/gopath/src/bitbucket.org/anacrolix/meme/cmd/meme$ go get bitbucket.org/anacrolix/meme/cmd/meme
can't load package: /home/matt/gopath/src/bitbucket.org/anacrolix/meme/cmd/meme/main.go:8:2: local import "../../../meme" in non-local package
matt#stanley:~/gopath/src/bitbucket.org/anacrolix/meme/cmd/meme$ echo $GOPATH
/home/matt/gopath
How do I import locally from a parent directory?
Edit: Relative import paths are not the way to go in Go. Lack of documentation shows something about popularity of relative paths, and I don't see a reason for using them. Go's recommended code organization works pretty well. Every package should have a unique import path and be imported everywhere using that same import path.
See how a package like github.com/ha/doozerd/peer imports its neighbors. This is a common practice among Go projects and I've seen it a lot of times. Package camlistore.org/pkg/auth (also on GitHub; written by one of the main authors of Go) imports camlistore.org/pkg/netutil by full path.
Even if you are having both commands and libraries in the same project this approach works. In your original questions you wisely asked for best practices. I did my best in explaining best practices on this matter.
Import paths can't be relative in Go. I recommend reading How to Write Go Code, the essential reading on organizing Go projects. Here's a short overview:
Make a directory like ~/go for your Go development. Then say:
$ export GOPATH=~/go
$ mkdir $GOPATH/{src,bin,pkg}
$GOPATH/src holds source code for all your Go packages, even the ones your download with go get. bin and pkg keep output of compilations. Packages with package name main are commands and yield to executable binaries which go to $GOPATH/bin. Other packages are libraries and their compiled object files are put in $GOPATH/pkg.
Now if you put your code in $GOPATH/src/matt/meme, you can import it by import "matt/meme". It's recommended to use a prefix for your package names and leave short package names for standard libraries. That's why I used $GOPATH/src/matt/meme instead of $GOPATH/src/meme.
Organize your code around this idea.
Thanks for adding to your question. First, an answer, then some explanation. I built your code by,
go get, just as you had it. (I ignored the error messages.)
setting the import line in main.go back to "../../../meme", as you wanted to do.
(commenting out a little bit of code containing an unused variable.)
then in the meme/cmd/meme directory, either go run main.go or go build main.go worked.
I was wrong in my comment earlier when I said go install works; I should have said go build.
The key however is that go build alone does not work; you must type go build main.go. This is because the go command does not allow "local imports in non-local packages." You are right that spec is of little help here. It weasels out saying, "The interpretation of the ImportPath is implementation-dependent." The current implementation behavior was set with CL 5787055, which was subsequently debated at length on Go-nuts.
"Local" means indicated with a file system relative path. Obviously a relative path starting with .. is local, so the trick is just getting the go command to treat main as a local package as well. It apparently doesn't do this when you type go build, but does when you type go build main.go.
Relarive imports are supported when manually using the compiler, linker, ... directly. The 'go' (build) tool doesn't support the same (somehow comparable to eg Java).
This may not answer the original question, but I was trying to do the above when I didn't really need to, all I needed to do was update go.mod temporarily with a replace :
module github.com/pselle/foo
replace github.com/pselle/bar => /Users/pselle/Projects/bar
require (
github.com/pselle/bar v1.0.0
)
reference:
https://thewebivore.com/using-replace-in-go-mod-to-point-to-your-local-module/