You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "Chris Schmautz (Jira)" <ji...@apache.org> on 2020/01/31 17:17:00 UTC

[jira] [Created] (AIRFLOW-6696) Package manager installable not a full distribution for rbac use

Chris Schmautz created AIRFLOW-6696:
---------------------------------------

             Summary: Package manager installable not a full distribution for rbac use
                 Key: AIRFLOW-6696
                 URL: https://issues.apache.org/jira/browse/AIRFLOW-6696
             Project: Apache Airflow
          Issue Type: Bug
          Components: ui
    Affects Versions: 1.10.7
            Reporter: Chris Schmautz


+Problem+

The 'pip' or 'conda' distribution of airflow is not a full distribution for anyone wanting a turn-key package. The 'dist' folder is not included in '.../www_rbac/static'.

 

+Proposed solution+

The expectation of the package manager is to have a useable asset once the package is installed. Packages relying on additional dependencies tend to stick with +sdist+ packaging route, so that they can expose those dependencies during build time (think C-backed packages, for instance).

 

'conda install airflow' did not expose this need for an additional step, and based on numerous other issues open in the Airflow backlog, chances are 'pip install' suffers the same fate.

 

Preferably for the proposed solution, just prescribe defaults for the 'dist' folder, and include ways to override it through some mechanism. Airflow already has this pattern for 'webserver_config.py', so the pattern is already there, if you'd want to extend the pattern to these assets. Whatever the solution, 'pip install' or 'conda install' should provide a usable, turn-key package without the need for an additional build system downstream.

 

+Why+

Many of our deployment targets don't have npm, and won't ever have it. We are then forced into a position of composing an environment at a tag revision, then using 'conda-pack' to send that revision to another place where the static resources can be built, back to a second 'conda-pack' with the built bundle. From our perspective, this build pattern has minimal lift over the previous static deployment path and is mainly a hassle.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)