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.

Sign up for GitHub

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

Remove commas in version-ranges #954

Merged
merged 2 commits into from
Dec 4, 2018
Merged

Remove commas in version-ranges #954

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
16294dd
Removed commas from version ranges
climblinne Nov 26, 2018
f76b086
Update version_ranges.rst
climblinne Nov 27, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 10 additions & 10 deletions mastering/version_ranges.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ The syntax is using brackets. The square brackets are the way to specify conan t
.. code-block:: python

class HelloConan(ConanFile):
requires = "Pkg/[>1.0,<1.8]@user/stable"
requires = "Pkg/[>1.0 <1.8]@user/stable"


So when specifying ``Pkg/[expression]@user/stable`` it means that ``expression`` will be evaluated as a version range. Otherwise it will be understand as plain text, so ``requires = "Pkg/version@user/stable"`` always means to use the version ``version`` literally.
Expand All @@ -21,26 +21,26 @@ There are some packages that do not follow semver, a popular one would be the Op
The process to manage plain versions vs version-ranges is also different. The second one requires a "search" in the remote, which is orders of magnitude slower than direct retrieval of the reference (plain versions), so take it into account if you plan to use it for very large projects.


Expressions are those defined and implemented by https://pypi.org/project/node-semver/,
but using a comma instead of spaces. Accepted expressions would be:
Expressions are those defined and implemented by https://pypi.org/project/node-semver/. Accepted expressions would be:

.. code-block:: python

>1.1,<2.1 # In such range
2.8 # equivalent to =2.8
~=3.0 # compatible, according to semver
>1.1 || 0.8 # conditions can be OR'ed
[>1.1 <2.1] # In such range
[2.8] # equivalent to =2.8
[~=3.0] # compatible, according to semver
[>1.1 || 0.8] # conditions can be OR'ed
[1.2.7 || >=1.2.9 <2.0.0] # This range would match the versions 1.2.7, 1.2.9, and 1.4.6, but not the versions 1.2.8 or 2.0.0.

Version range expressions are evaluated at the time of building the dependency graph, from
downstream to upstream dependencies. No joint-compatibility of the full graph is computed, instead,
version ranges are evaluated when dependencies are first retrieved.

This means, that if a package A depends on another package B (A->B), and A has a requirement for
``C/[>1.2,<1.8]``, this requirement is evaluated first and it can lead to get the version ``C/1.7``. If
package B has the requirement to ``C/[>1.3,<1.6]``, this one will be overwritten by the downstream one,
``C/[>1.2 <1.8]``, this requirement is evaluated first and it can lead to get the version ``C/1.7``. If
package B has the requirement to ``C/[>1.3 <1.6]``, this one will be overwritten by the downstream one,
it will output a version incompatibility error. But the "joint" compatibility of the graph will not
be obtained. Downstream packages or consumer projects can impose their own requirements to comply
with upstream constraints, in this case a override dependency to ``C/[>1.3,<1.6]`` can be easily defined
with upstream constraints, in this case a override dependency to ``C/[>1.3 <1.6]`` can be easily defined
in the downstream package or project.

The order of search for matching versions is as follows:
Expand Down