Skip to content
This repository was archived by the owner on Dec 9, 2024. It is now read-only.
This repository was archived by the owner on Dec 9, 2024. It is now read-only.

options for using autover #57

@ceball

Description

@ceball

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions