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

options for using autover #57

Open
ceball opened this issue Oct 12, 2018 · 0 comments
Open

options for using autover #57

ceball opened this issue Oct 12, 2018 · 0 comments
Labels

Comments

@ceball
Copy link
Member

ceball commented Oct 12, 2018

Attempt to summarize previous discussions along the lines of, 'Why did
we put autover into param?', out of the 5 or so possible options.

Could consider adding to autover's docs; otherwise, should just close
this issue.

1. versioning code embedded at top level of all git repos, but not
in any package. Autover contains the master copy. Could have tool to
check all repos are up to date.

pros:

  • once embedded, will definitely be available under all circumstances

  • same approach works for pyviz and non pyviz projects (one set of
    instructions, one way to test)

  • simple __init__ code: __version__ = str(param.version.Version(fpath=__file__, archive_commit="$Format:%h$",reponame="holoviews"))

  • a project that is happy with its working versioning workflow won't
    ever have to change when autover is updated

cons:

  • has to be kept up to date! whereas all other options mean a
    change to autover is easy to propagate to other projects

  • bloats every repo (one file in repo with 550 lines of code, though
    still less than versioneer's 2300 loc with 2 files plus at least 2
    config file changes)

2. versioning code embedded only in param git repo, also published
in param package, and all pyviz tools fetch from param package (or
git) at build time (which includes package build and git repo usage)

pros:

  • simple __init__ code (as above, but unlike 3) for any project with
    a run time dependency on param

cons:

  • forces param to publish (and document? and test?) versioning code,
    making the param package more complex

3. as 2, but from pyct instead (which means param would have build
time dependency on versioning code)

pros:

  • makes more sense (in that versioning relates to pyct.build but not
    param)

  • can update versioning without updating param

cons:

  • more complex init code in all projects if those projects don't
    have a runtime dependency on pyct (and there'll be -core versions
    of those projects that don't depend on pyct already):

    # version comes from git if available, otherwise from .version file
    try:
        from pyct.build import Version
        __version__ = str(Version(fpath=__file__,archive_commit="$Format:%h$",reponame="nbsite"))
    except:
        import os, json
        __version__ = json.load(open(os.path.join(os.path.dirname(__file__),'.version'),'r'))['version_string']
        del os, json

4. all packages depend on autover package at build time

pros:

  • clear separation of packages

cons:

  • the same complex __init__ code as in 3

  • multiple build time dependencies (autover and pyct)

5. all packages depend on autover at run time as well as build time

pros:

  • same pro of simple __init__ in 2

  • same pro as 4 (separation of packages)

  • simpler for developers (always need autover)

cons:

  • extra run time dependency
@ceball ceball added the doc label Oct 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant