Merge pull request #1190 from davydden/feature/version_dev

add special treatment of @develop version
This commit is contained in:
Todd Gamblin 2016-07-11 11:31:54 -07:00 committed by GitHub
commit 7f6541ef02
4 changed files with 37 additions and 11 deletions

View File

@ -568,7 +568,7 @@ The package author is responsible for coming up with a sensible name
for each version to be fetched from a repository. For example, if for each version to be fetched from a repository. For example, if
you're fetching from a tag like ``v1.0``, you might call that ``1.0``. you're fetching from a tag like ``v1.0``, you might call that ``1.0``.
If you're fetching a nameless git commit or an older subversion If you're fetching a nameless git commit or an older subversion
revision, you might give the commit an intuitive name, like ``dev`` revision, you might give the commit an intuitive name, like ``develop``
for a development version, or ``some-fancy-new-feature`` if you want for a development version, or ``some-fancy-new-feature`` if you want
to be more specific. to be more specific.
@ -578,6 +578,17 @@ branches move forward over time and you aren't guaranteed to get the
same thing every time you fetch a particular version. Life isn't same thing every time you fetch a particular version. Life isn't
always simple, though, so this is not strictly enforced. always simple, though, so this is not strictly enforced.
When fetching from from the branch corresponding to the development version
(often called ``master``,``trunk`` or ``dev``), it is recommended to
call this version ``develop``. Spack has special treatment for this version so
that ``@develop`` will satisfy dependencies like
``depends_on(abc, when="@x.y.z:")``. In other words, ``@develop`` is
greater than any other version. The rationale is that certain features or
options first appear in the development branch. Therefore if a package author
wants to keep the package on the bleeding edge and provide support for new
features, it is advised to use ``develop`` for such a version which will
greatly simplify writing dependencies and version-related conditionals.
In some future release, Spack may support extrapolating repository In some future release, Spack may support extrapolating repository
versions as it does for tarball URLs, but currently this is not versions as it does for tarball URLs, but currently this is not
supported. supported.
@ -603,7 +614,7 @@ Default branch
class Example(Package): class Example(Package):
... ...
version('dev', git='https://github.com/example-project/example.git') version('develop', git='https://github.com/example-project/example.git')
This is not recommended, as the contents of the default branch This is not recommended, as the contents of the default branch
change over time. change over time.
@ -676,7 +687,7 @@ Default
.. code-block:: python .. code-block:: python
version('hg-head', hg='https://jay.grs.rwth-aachen.de/hg/example') version('develop', hg='https://jay.grs.rwth-aachen.de/hg/example')
Note that this is not recommended; try to fetch a particular Note that this is not recommended; try to fetch a particular
revision instead. revision instead.
@ -708,7 +719,7 @@ Fetching the head
.. code-block:: python .. code-block:: python
version('svn-head', svn='https://outreach.scidac.gov/svn/libmonitor/trunk') version('develop', svn='https://outreach.scidac.gov/svn/libmonitor/trunk')
This is not recommended, as the head will move forward over time. This is not recommended, as the head will move forward over time.
@ -718,7 +729,7 @@ Fetching a revision
.. code-block:: python .. code-block:: python
version('svn-head', svn='https://outreach.scidac.gov/svn/libmonitor/trunk', version('develop', svn='https://outreach.scidac.gov/svn/libmonitor/trunk',
revision=128) revision=128)
Subversion branches are handled as part of the directory structure, so Subversion branches are handled as part of the directory structure, so

View File

@ -166,6 +166,10 @@ def prefer_key(v):
valid_versions.sort(key=prefer_key, reverse=True) valid_versions.sort(key=prefer_key, reverse=True)
if valid_versions: if valid_versions:
# Disregard @develop and take the next valid version
if ver(valid_versions[0]) == ver('develop') and len(valid_versions) > 1:
spec.versions = ver([valid_versions[1]])
else:
spec.versions = ver([valid_versions[0]]) spec.versions = ver([valid_versions[0]])
else: else:
# We don't know of any SAFE versions that match the given # We don't know of any SAFE versions that match the given

View File

@ -92,6 +92,9 @@ def test_two_segments(self):
self.assert_ver_eq('1.0', '1.0') self.assert_ver_eq('1.0', '1.0')
self.assert_ver_lt('1.0', '2.0') self.assert_ver_lt('1.0', '2.0')
self.assert_ver_gt('2.0', '1.0') self.assert_ver_gt('2.0', '1.0')
self.assert_ver_eq('develop', 'develop')
self.assert_ver_lt('1.0', 'develop')
self.assert_ver_gt('develop', '1.0')
def test_three_segments(self): def test_three_segments(self):
self.assert_ver_eq('2.0.1', '2.0.1') self.assert_ver_eq('2.0.1', '2.0.1')

View File

@ -236,6 +236,14 @@ def __lt__(self, other):
if self.version == other.version: if self.version == other.version:
return False return False
# dev is __gt__ than anything but itself.
if other.string == 'develop':
return True
# If lhs is dev then it can't be < than anything
if self.string == 'develop':
return False
for a, b in zip(self.version, other.version): for a, b in zip(self.version, other.version):
if a == b: if a == b:
continue continue