You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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 filetry:
frompyct.buildimportVersion__version__=str(Version(fpath=__file__,archive_commit="$Format:%h$",reponame="nbsite"))
except:
importos, json__version__=json.load(open(os.path.join(os.path.dirname(__file__),'.version'),'r'))['version_string']
delos, 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
The text was updated successfully, but these errors were encountered:
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:
__init__
code (as above, but unlike 3) for any project witha run time dependency on param
cons:
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):
4. all packages depend on autover package at build time
pros:
cons:
the same complex
__init__
code as in 3multiple 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 2same pro as 4 (separation of packages)
simpler for developers (always need autover)
cons:
The text was updated successfully, but these errors were encountered: