- . contents:: Releases
local:
Parse
git describe
like setuptools_scm plugin does.Drop pvcmd/pvtags.py, and replace it with polyversion?
Engravings: Not easy to extend!
Configurable hooks - refactor :term:`engravings` as one of them. to run, for example, housekeeping commands on all subprojects like
pip install -e <project>
and immediately start working in "develop mode".This would allow housekeeping commands and validate tests before/after every bump:
## Pre-release hook # pytest tests ## Post-release hook # rm -r dist/* build/*; python setup.py sdist bdist_wheel twine upload dist/*whl -s
Add top-level engrave glob-excludes.
Use astor grafter.
Refactor :term:`version-bump algebra` to support a single modifier per segment (see
multivermath
branch).Lock release-trains as "alpha/beta".., specific branches can be selected Based on :term:`version-bump algebra`), this will force users to always use
pip install --pre
to fetch such release-trains. This is a safeguard to avoid accidentally landing half-baked code to users.Retrofit polyversion library as a plugin of polyvers command.
Function as plugin for other 3rd-party projects, bake a cookiecutter
Check what happens with no-commit, e.g. to temporarily package a wheel.
Maintenance release.
- enh: polyversion now logs which was cmd not found on Windows
(usually it is executing
git
). - chore: Merge all pyupd requests for dependencies.
FIX: git < 2.15.0 was buggy with multiple match-patterns in command:
git describe --match=... --match=...
(see https://github.com/git/git/blob/master/Documentation/RelNotes/2.15.0.txt)
The
polyvers
cmd still affected by this.
FIX: engravings were applied unsorted (based on their start-point) and offsets were miss-located when switching graft in a same file.
- Feature: The :envvar:`POLYVERSION_LOG_LEVEL` control polyversion verbosity.
Run
polyversion -h
fo help. - Change: minor reordering when searching version from package-metadata.
- fix: add standalone
bin/pvlib.run
from last release. - fix: :func:`~polyversion.polyversion()`/:func:`~polyversion.polytime()`
are guessing
basepath
keyword from the path of caller's top-package (not just from caller's fpath).
- Version v0.2.0a0 not in pypi, consumed for standalone
bin/pvlib.run
. - Version v0.2.0a1 were not finding sbling-dir versions if
pip install git+...
, and had not replaced all skip-bdist flags.
- Teach non-engraved projects how to retrieve polyversion when pip-installed:
- The functions :func:`~polyversion.polyversion()` & :func:`~polyversion.polytime()` now attempt to fetch version from package/site-package infos.
- And the function doing this :func:`polyversion.pkg_metadata_version()`
retrofitted to:
- search for <pname-<version>.egg-info/PKG-INFO in baspath sibling folder (before searching PKG-INFO, METADATA in basepath),
- so now basepath always needed in
polyversion()/polytime()
functions to locate sibling dir.
- Rename :term:`setuptools` flag from
skip_polyversion_check --> polyversion_check_bdist_enabled
to flip its default logic (not checking by default), since non-engraved wheels install just fine now. - Rename the keyword of
polyversion()
/polytime()
functions fromrepo_path --> basepath
to denote its importance for retrieving the version of installed projects from sibling dirs insidePYTHONPATH/site-packages/
.
(change actually done in v0.1.1a1, just a fixes & doc-msg in a2)
- FIX: teach :term:`setuptools plugin` about :term:`default version env-var`.
Now can
pip install git+https://some.git.repo/but-from/non-engraved-branch
.
- FEAT: Introduce configurable :term:`default version env-var` to fall-back
to :envvar:`<pname>_VERSION` if it exists, in case of errors (e.g. no git).
The presence of such a variable also sets
polytime(no_raise=True)
, which now also support thepname
anddefault_version_env_var
kwds.
Mostly docs, combined release.
- FEAT: reinstated :term:`engravings` on
_version.py
(see previous release for rational).
- FEAT: reinstated :term:`engravings` on
setup.py
(dropped only for a while in 2018-06-03: polyversion-v0.1.0a3: setuptools ), since, assuming clients have adopted the new :term:`setuptools plugin` keyword, it is the default_version that will be engraved, which is fine. - fix: report any version matched both from :term:`v-tag`s and :term:`r-tag`'s.
- fix:
bump
command does not engrave egg-related files. polyversion
command got a bit more civilized (with logging to explain problems with related stacktraces.- dev: don't test building wheel on travis...too much fuzzz.
- Disable standalone-wheel hack from
pvlib/setup.py
and rely on setuptools plugin even for polyversion ONCE MORE. (but no need to update standalone, which is a wheel, unaffected by that)
Bugfixing polyversion (and generate a non-buggy standalone wheel):
FIX polyversion where it ignored
setup(default_version
keyword. (:git:`6519a1ba`)fix: polyversion stop eating half of its own dog food: cannot reliably use :term:`setuptools plugin` for its installation. (:git:`56a894cde`)
Monkeypatching distutils for :term:`bdist-check` was failing in PY2 due to being an "old class". (:git:`1f72baec`)
doc: fixed recommendation about how to bypass :term:`bdist-check` to this:
... You may bypass this check and create a package with non-engraved sources (although it might not work correctly) by adding skip_polyversion_check option in your
$CWD/setup.cfg
file, like this:[global] skip_polyversion_check = true ...
v0.1.0a2`Canceled (like the previous 2), cannot release from r-tags because ``setup()` reports version from v-tag.
- Q: Is a new setup-keyword needed
--is-polyversion-release
? - A: no, just search both.
- Q: Is a new setup-keyword needed
v0.1.0a0 had been canceled for the same reason, but somewhere down the road, the fix was reverted (:term:`bdist-check` works for r-tag only).
v0.1.0a1 just marked that our
setup.py
files ate our dog food.
Dropped all positional-arguments from :func:`polyversion.polyversion()`; was error-prone. They have all been converted to keyword-arguments.
Renamed data in :mod:`polyversion` (also applied for :class:`polyvers.pvproject.Project()`):
pvtag_frmt --> pvtag_format vtag_frmt --> vtag_format
Changed arguments in :func:`polyversion.polyversion()` (affect also :class:`polyvers.pvproject.Project()`):
default --> default_version tag_frmt --> tag_format --> vprefixes (new) --> is_release (new)
REVERTED again the 0.0.2a9 default logic to raise when it version/time cannot be derived. Now by default it raises, unless default-version or
no_raise
for :func:`polyversion.polytime()`.Stopped engraving
setup.py
files ; clients should use setuptools plugin to derive version for those files (see new features, below)). For reference, this is the removed element from default :class:`~Project`'s configuration (in YAML):globs: [setup.py] grafts: - regex: -| (?xm) \bversion (\ *=\ *) .+?(, \ *[\n\r])+
polyversion library searches both v-tags and r-tags (unless limited). Previously, even checked-out on an r-tag, both
polyversion
command andpolyvers bump
would ignore it, and report +1 from the v-tag!
The polyversion library function as a setuptools "plugin", and adds two new
setup()
keywords for deriving subproject versions from PKG-INFO or git tags (see :func:`polyversion.init_plugin_kw`):- keyword:
polyversion --> (bool | dict)
When a dict, its keys roughly mimic those in :func:`polyversion()`, and can be used like this:
from setuptools import setup setup( project='myname', version='' # omit (or None) to abort if cannot auto-version polyversion={ # dict or bool 'mono_project': True, # false by default ... # See `polyversion.init_plugin_kw()` for more keys. }, setup_requires=[..., 'polyversion'], ... )
- keyword:
keyword:
skip_polyversion_check --> bool
When true, disable :term:`bdist-check`, when false (default), any bdist_* (e.g.bdist_wheel
), commands will abort if not run from a :term:`release tag`. You may bypass this check and create a package with non-engraved sources (although it might not work correctly) by invoking the setup-script from command-line like this:$ python setup.py bdist_wheel --skip-polyversion-check
- bump cmd: engrave also non-bumped projects with their
git describe
-derived version (controlled by
--BumpCmd.engrave_bumped_only
flag).
- bump cmd: engrave also non-bumped projects with their
Assign names to engraves & grafts for readable printouts, and for refering to them from the new Project.enabled_engarves list. (namengraves)
polyversion -t
command-line tool prints the full tag (not the version) to make it easy to know if it is a v-tag or r-tag.
- Adopt towncrier for compiling CHANGES. So now each code change can describe its change in the same commit, without conflicts. (towncrier)
- usage: explain how to set your projects PEP 0518
pyproject.toml
file &setup_requires
keyword insetup.py
in your script. - add pbr, incremental and Zest.release in :ref:`similar-tools` section as setuptools plugins.
- re-wrote and shrinked opening section using glossary terms.
- Chore development:
- deps: don't pin packaging==17.1, any bigger +17 is fine for parsing version correctly.
- fix: slight change of default engraving for
setup.py:version=...
. - Remove default versions from the sources of our-own-dog-food (affects installations for developing this tool).
- refact: merged
`pvlib.whl
andpvlib.run
into a single executable and importable standalone wheel inbin/pvlib.run
, generated frompolyversion-0.0.2a9
, release below. - doc: expand section for installing and contributing into this project.
- chore: tighten various test harnesses.
2nd interim release to embed new bin/pvlib.run
.
- INVERT by default
polyversion()/polytime()
functions not to raise if vtags missing. - fix: pvlib.run shebang to use
#!/usr/bin/env python
to work on linux.
Interim release to embed new bin/pvlib.run
.
- FIX
polyversion
barebone command (a utility for when not installing the full polyvers tool). - feat: make project-name optional in :func:`polyversion.polyversion()`; if not given, defaults to caller's last segment of the module.
- doc: rudimentary explanation of how to use the lib on its own README.
- feat: add
-C
option to change project dir before running command. init
command:- fix: were creating invalid
.polyvers.yaml
configuration-file unless--monorepo/--mono-project
flags were given. - feat: include config-help in generated file only if
the new
--doc
flag given. - feat: inform user of the projects auto-discovered and what type of config-file was generated.
- fix: were creating invalid
- various fixes.
- FIX(bump): was engraving all projects and not limiting to those specified in the command-line - command's syntax slightly changed.
- chore: Stop increasing polyversion version from now on.
- doc: fix all sphinx errors and API reference.
Interim release to embed re-LICENSED pvlib/bin/pvlib.whl
,
from EUPLv1.2-->MIT
bump
command:- feat:
--amend
now works - feat:
--engrave-only
. - feat: log
PRETEND
while doing actions. - feat: Log which files where engraved in the final message.
- feat:
- fix(engrave): don't waste cycles/log-messages on empty-matches (minor).
Actually most changes happened in "interim" release v0.0.2a2, below.
- feat: make a standalone polyversion-lib wheel to facilitate bootstrap when installing & building from sources (and the lib is not yet installed).
- Add
bin/package.sh
that create the pvlib wheel as executabledist/pvlib.run
. - doc: fix rtd & pypi sites.
doc: bad PyPi landing page.
The pvcmd was actually broken so far; was missing polyversion lib dependency!
Interim release to produce executable wheel needed by next release.
- 2nd release, own "mono-project" splitted into 2-project "monorepo": - polyvers: cmdline tool - polyversion: library code for program-sources to derive version from git-tags
- init, status, bump and config commands work.
- Read/write YAML config file
.polyvers.yaml
at the git-root, and can automatically discover used configuration (from existing git tags or projects files). - Support both
--monorepo
and--mono-project
configurations. - By default
__init__.py
,setup.py
andREADME.rst
files are engraved with bumped version.
broken
- First release on PyPI as mono-project