-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
[AIRFLOW-116] Add a version view to display airflow version info #1504
Conversation
# Get the Git repo and git hash : first try pip freeze, then look at git | ||
git_repo = git_hash = None | ||
try: | ||
p = subprocess.Popen('pip freeze | grep airflow', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little bit uncomfortable about adding a dependency on PIP (also it's possible that the running version of airflow doesn't match this version if e.g. it has a different PYTHONPATH). One idea is to show the hard-coded airflow version plus have a version file generated by setup-tools if this is possible indicating the SHA of the repo used to generate the package if relevant (this can be in v2). Since Airflow is aware of where it is running from it would always use the right "version" file. With this approach we would also remove the dependency on git (since the version would just be read from a file). The git dependency would be moved to the deploy process (generating the version file with the SHA) which is cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pip is the recommended way to install python packages as it lets you easily rollback, not to mention its the first step all of us took as per the folowing link http://pythonhosted.org/airflow/start.html
Also, this is a soft dependency. If PIP is not available, it will fall through to the git implementation.
After a while, most people decided to run off their own forks. This is partly due to the unpredictably long release cycles. For those folks, they will install from their own git repos.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand I'm just not sure it's a good idea to create a dependency on PIP/git in the code as it violates separation of concerns (the code shouldn't know anything about what service it is deployed with), might be worth getting some more opinions on this. Also there is the issue with pip returning the wrong version (e.g. due to PYTHONPATH being off or airflow being run in a virtualenv). Same goes for the git dependency (unless we can move that to the deploy process).
Would be useful to get some more opinions on this:
cc @criccomini @plypaul @jlowin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check out how I do it in Caravel:
https://github.com/airbnb/caravel/blob/master/setup.py#L4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the git case, I load the repo based on where $AIRFLOW_HOME points. That pointer is authoritative. In terms of the PYTHONPATH and venv cases, I'd love some examples. I personally run off a git fork and use python setup.py install
to install the code. However, many in the community don't maintain forks and instead using pip to install
Consider that we have users and developers. Most users tend to install using standard package managers. Today, since our user documentation points to pip and also since pip plays better with automation (e.g. easy to roll forward and backward), I don't think pip will go away.
-s
51ec852
to
ae02ea7
Compare
|
||
# Render information | ||
title = "Version Info" | ||
git_proj_uri = git_repo.replace('git@','').replace('.git','').replace(":","/") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
space after commas in calls
@@ -15,6 +15,8 @@ | |||
import sys | |||
|
|||
import os | |||
import pip |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dd
repo = Repo(os.path.expanduser(settings.AIRFLOW_HOME)) | ||
head_commit = repo.head.commit | ||
git_hash = head_commit.hexsha | ||
git_repo=repo.remotes.origin.url |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oddly my git repo for airflow doesn't have an origin since I prefer using org names, this would raise
{% block body %} | ||
{{ super() }} | ||
<h2>{{ title }}</h2> | ||
{% if airflow_version %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aoen
I suspect your comment was on the wrong line. There was a duplicate title earlier, but that has been removed yet your comment persists. Please clean up and I will do the same of this comment.
I like the way version is handled now (I didn't like depending on |
I've been thinking about this and I think the right time to get a git SHA is at build time (so in setup.py). After that you can't assume that the python files are in a Git repo. They're most likely in a virtualenv or |
Maybe a dumb question. What happens for the vast majority of people who are using pip to install? I'm not familiar with what happens during the Pypi creation process -- @aoen are you ensuring that a git hash file is created at that time? Adding support in setup.py handles a small minority of cases (e.g. developers), but ignores the vast majority of cases (users). |
Thinking about the build-time commit hash a bit. A (hacky) way of doing this would be to just add a subproc call in setup.py that runs:
And then making sure that setup.py bundles the file in the package appropriately. A more elegant solution would be to use the |
In my initial comment:
I meant something like @criccomini mentioned (although more along the lines of |
I'm moving ahead with moving the "git code" above to setup.py. |
It looks like this (infrequent releases and getting a git hash at setup time) is a problem others have discussed as well : Lasagne/Lasagne#574 @criccomini @mistercrunch @aoen |
@aoen I tried https://github.com/pyfidelity/setuptools-git-version, the link you posted above. Where is the git version written for setup.py develop and install? |
I don't think it is unfortunately, this small function on SO might be helpful though (taking the output of that and writing it to a file): |
@aoen What about |
<h4>Version : Not Available</a></h4> | ||
{% endif %} | ||
|
||
{% if git_version %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: use same title for both of these (git version vs git commit tree), can also refactor this to avoid duplication (the only difference being "{{ git_version }}" vs "Not Available"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you provide a snippet? It might be clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see vis-a-vis title, but I suspect you are thinking of a ternary operator to squeeze this in to a single line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can keep the current operator just bring it's scope in a little:
<h4>Git Version :{% if git_version %} {{ git_version }} {% else %} Not Available {% endif %}</a> <h4>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx for the template foo!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh. looks like these comments are on the wrong lines.
}, | ||
) | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 seems standard. I need to install flake8 on my box now that we don't have landscape.io running. But, I'm pretty sure 2 is adequate. Your earlier comment was when there were 3.
Please remove comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PEP8 says 2 lines before classes and function definition but not before an if. It's really not shocking though when landscape.io
starts policing again it will note this as a "code smell". You can get flake8
to install commit hooks so that you see those on commit. flake8 --install-hook
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are all addressed in a new PR : https://github.com/apache/incubator-airflow/pull/1523/files
6747bde
to
a331167
Compare
@@ -35,6 +38,44 @@ def run(self): | |||
os.system('rm -vrf ./build ./dist ./*.pyc ./*.tgz ./*.egg-info') | |||
|
|||
|
|||
def git_version(version): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+doc string
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:
The code supports both release and develop versions and works for both python setup.py develop/install.