Remove reference to commit IDs

[hdoupe]

This PR removes the reference to the commit ID for taxcalc, ogusa and btax as requested in #612. Since all of these packages are versioned, there is no need to pin them to the version and specific commit.

[hdoupe]

Then link still points towards https://github.com/open-source-economics/Tax-Calculator.

How do I edit the html code so that it points towards:
https://github.com/open-source-economics/Tax-Calculator/tree/0.9.2

In Python, I would do something like this:

<p><a href="https://github.com/OpenSourcePolicyCenter/Tax-Calculator/tree/{}".format(taxcalc_version)>Version {{ taxcalc_version }} - GitHub</a></p>

@GoFroggyRun @brittainhard

[martinholmer]

@hdoupe asked:

How do I edit the html code so that it points towards:
https://github.com/open-source-economics/Tax-Calculator/tree/0.9.2

I don't think this needs to be an HTML link does it?
We just wan the correct release number (for example, 0.9.2).

[hdoupe]

@martinholmer I think that the link should point towards the version that the webapp is using. This PR shows the version of the Tax-Calculator that TaxBrain is using but when you click the link it takes you to
https://github.com/open-source-economics/Tax-Calculator

instead of

https://github.com/open-source-economics/Tax-Calculator/tree/0.9.0

[martinholmer]

@hdoupe said:

I think that the link should point towards the version that the webapp is using. This PR shows the version of the Tax-Calculator that TaxBrain is using but when you click the link it takes you to

https://github.com/open-source-economics/Tax-Calculator

instead of

https://github.com/open-source-economics/Tax-Calculator/tree/0.9.0

OK. If you have the version/release number (for example, 0.9.0) in a variable, then can't you construct the second URL above in a variable called (say) unique_url.taxcalc_release using Python string operations? And then you can refer to that as the hyperlink in the HTML code.

Do you know where in the code the variable unique_url.taxcalc_vers is set?

[martinholmer]

@hdoupe, #622 is good progress, but can we add just two more things?

First, everywhere we have the phase "created_on|date", can we add the time zone, UTC.
That UTC string would be part of the HTML code, right?
This phrase occurs three time in the source code, as best as I can tell.

And second, can the sentence containing the "created_on|date" phrase, read like this?

These results were generated by TaxBrain version {{ ... }} on ...date... using Tax-Calculator version {{ ... }}

I think you can get the TaxBrain version by calling _version.get_versions()['version'].
Is that correct?

@brittainhard

[hdoupe]

@martinholmer Sounds good to me. I'll add these suggestions.

[hdoupe]

@martinholmer said

And second, can the sentence containing the "created_on|date" phrase, read like this?

These results were generated by TaxBrain version {{ ... }} on ...date... using Tax-Calculator version {{ ... }}

This seems sensible to me but I got the following result:

I think there may be an issue with how the version is set. Lines 21-24 of taxbrain_server/_version.py are

# these strings are filled in when 'setup.py versioneer' creates _version.py
tag_prefix = ""
parentdir_prefix = "taxcalc-"
versionfile_source = "taxcalc/_version.py"

and taxbrain_server/__init__.py is blank even after running the installation process.

But in taxcalc the corresponding lines are

# these strings are filled in when 'setup.py versioneer' creates _version.py
tag_prefix = ""
parentdir_prefix = "taxcalc-"
versionfile_source = "taxcalc/_version.py"

and __init__.py contains

from taxcalc._version import get_versions
__version__ = get_versions()['version']
del get_versions

I thought that maybe you had to run python setup.py versioneer to set up the version reporting function in taxbrain_server/__init__.py. It did do this, but it doesn't refer to the correct version. Lines 21-24 of taxbrain_server/_version.py became

tag_prefix = ""
parentdir_prefix = "taxbrain_server-"
versionfile_source = "taxbrain_server/_version.py"

and __init__.py now contains

from ._version import get_versions
__version__ = get_versions()['version']
del get_versions

However, when I tried to retrieve the version:

In [1]: from _version import get_versions

In [2]: get_versions()
Out[2]: {'full': '', 'version': 'unknown'}

But when I do the same thing for Tax-Calculator, I get:

In [1]: from _version import get_versions

In [2]: get_versions()
Out[2]: 
{'full': '320d7b107c5a0121e5add720ca8d6cbd0e99394c',
 'version': '0.9.2-85-g320d7b10'}

It looks like taxbrain_server/_version.py is not finding the correct version of the webapp. I'm not very familiar with versioneer but I can try to figure this out. Does anyone have any idea what's going on here or where I should start looking?

@brittainhard

[martinholmer]

@brittainhard, How does one get the version of TaxBrain (that is, the webapp-public release number, 1.y.z)?
It has been almost three weeks since @hdoupe asked how to do this. See a description of his problem here in 622. Can you give him some advice?

[brittainhard]

@martinholmer i'll take a look.

[hdoupe]

Thanks @brittainhard

[brittainhard]

@hdoupe @martinholmer there are a couple of solutions to this.

Since TaxBrain isn't a python package, the only way to know its version is by getting the latest git tag. In the app, you would have to make a subprocess call like this:

import subprocess
import shlex
call = subprocess.Popen(
    shlex.split("git describe --abbrev=0 --tags"),
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE
)
result = call.communicate()
print(result[0]) # The tag

However, I think it is a better idea to set a string constant variable that provides the version. In the settings file you could add TAXBRAIN_VERSION="v1.0.1". Then, in the views file you can add from django.conf import settings and then to get the version taxbrain_version = settings.TAXBRAIN_VERSON.

Since the webapp version isn't something that changes often, it's not worth it to make a programmatic call to get the current version every time a page is loaded. I suggest going with the second option.

Let me know if you have any questions.

@martinholmer I appreciate the ping on this one. There's lots of stuff to keep track of, and some things just slip through the cracks.

[martinholmer]

@brittainhard said:

Since TaxBrain isn't a python package, the only way to know its version is by getting the latest git tag. In the app, you would have to make a subprocess call like this:

CODE FRAGMENT

However, I think it is a better idea to set a string constant variable that provides the version. In the settings file you could add TAXBRAIN_VERSION="v1.0.1". Then, in the views file you can add from django.conf import settings and then to get the version taxbrain_version = settings.TAXBRAIN_VERSON.

Thanks for the helpful information.

But I have one question. If versioneer doesn't provide the TaxBrain version, what does it do in webapp-public? Put another way: Why don't we eliminate versioneer from the webapp-public repo?

@hdoupe

[brittainhard]

@martinholmer I know there is a versioneer script for the deploy folder (since it used to be a separate repository) but I don't think there is one for webapp. In that case its probably wise to remove the deploy versioneer script.

I think that since there is no standard release process for webapp (just version tagging with a string) there wouldn't be much use for versioneer.

EDIT: By "standard release process" I mean a release process that uses conda or pypi and a setup.py script.

[martinholmer]

@brittainhard said:

I know there is a versioneer script for the deploy folder (since it used to be a separate repository) but I don't think there is one for webapp. In that case its probably wise to remove the deploy versioneer script.

I think that since there is no standard release process for webapp (just version tagging with a string) there wouldn't be much use for versioneer.

By "standard release process" I mean a release process that uses conda or pypi and a setup.py script.

@brittainhard, Thanks for the explanation.
@hdoupe, Seems like you should add this to your remove-unneed-code list.

@MattHJensen

[hdoupe]

Thanks @martinholmer and @brittainhard

[hdoupe]

@martinholmer @MattHJensen Do you think that we should use "Webapp-Public version 1.0.1" or
"TaxBrain version 1.0.1" when the version is displayed? The version applies to the entire website right now including the CCC. So, it would make more sense to me to reference "Webapp-Public" instead of "TaxBrain."

[martinholmer]

@hdoupe asked:

Do you think that we should use "Webapp-Public version 1.0.1" or
"TaxBrain version 1.0.1" when the version is displayed? The version applies to the entire website right now including the CCC. So, it would make more sense to me to reference "Webapp-Public" instead of "TaxBrain."

Good points. However, I don't think anybody but the developers will understand "Webapp-public".
Why not just "Webapp" or "webapp" depending on whether you're going to use "Tax-Calculator" or "taxcalc"?

I assume that in your question, you meant to refer to 1.0.2, right? Isn't that the next webapp version that will be using taxcalc 0.10.2 (or 0.10.x if you find more taxcalc bugs)?

[hdoupe]

However, I don't think anybody but the developers will understand "Webapp-public".
Why not just "Webapp" or "webapp" depending on whether you're going to use "Tax-Calculator" or "taxcalc"?

That makes sense. I'm going with "Tax-Calculator." I'll use "Webapp" unless @MattHJensen objects. We could change it in the future, too.

I assume that in your question, you meant to refer to 1.0.2, right? Isn't that the next webapp version that will be using taxcalc 0.10.2 (or 0.10.x if you find more taxcalc bugs)?

Yep, 1.0.2 is the right version. Nice catch.

[MattHJensen]

@hdoupe, my preference is "PolicyBrain." I also plan to rename the repo, and eventually we ought to separate ospc.org content to a separate repo.

@martinholmer @GoFroggyRun

[hdoupe]

@MattHJensen Ok sounds good to me.

[MattHJensen]

I just changed the repo name 💥

[hdoupe]

@MattHJensen Awesome, I'll make the path changes in this PR, too.

[MattHJensen]

Thanks. All of the old paths will remain active, so I do not believe that the update is urgent. But it is certainly good to do.

[hdoupe]

@MattHJensen Ah, right. Never mind.

[hdoupe]

@brittainhard @GoFroggyRun This PR is ready for review.

[hdoupe]

@brittainhard @GoFroggyRun This PR is ready for review.

Nevermind, I'll take a look at this.

[hdoupe]

Ok, now this is ready for review.

[GoFroggyRun]

@hdoupe This PR looks good to me. But you might want to take a look at those merging conflicts resulting from recent merge of #641 .

[hdoupe]

@GoFroggyRun Thanks for the review. I'll take a look at this.

[brittainhard]

LGTM, merging.