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.

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

Feature/versioning WIP #1350

Merged
merged 7 commits into from Jul 9, 2019
Merged

Feature/versioning WIP #1350

merged 7 commits into from Jul 9, 2019

Conversation

@memsharded
Copy link
Member

@memsharded memsharded commented Jul 4, 2019

NOT FINISHED, but to gather quick feedback about the structure and the moving of version ranges and package revisions.

@memsharded memsharded added this to the 1.17 milestone Jul 4, 2019
@lasote
Copy link
Contributor

@lasote lasote commented Jul 4, 2019

I think it is better. Go ahead

As a possible disadvantage, it requires the consumers to explicitly modify the recipes
to use updated versions, which could be tedious or difficult to scale for large projects
with many dependencies, in which those dependencies are frequently modified, and
it is desired to move the whole project forward to those updated dependencies.
Copy link
Contributor

@lasote lasote Jul 9, 2019

Suggested change
it is desired to move the whole project forward to those updated dependencies.
it is desired to move the whole project forward to those updated dependencies.
To mitigate that issue, especially while developing the packages, you can use fixed versions with `package revisions` (see below) to resolve automatically the latest revisions for a given fixed version.


- :command:`--lockfile` argument in :command:`install/create/export/info`

If the command builds a package, it can modify its reference. Even if teh version is not changed,
Copy link
Contributor

@lasote lasote Jul 9, 2019

Suggested change
If the command builds a package, it can modify its reference. Even if teh version is not changed,
If the command builds a package, it can modify its reference. Even if the version is not changed,


.. code-block:: bash
$
Copy link
Contributor

@lasote lasote Jul 9, 2019

?

$ cd PkgB
$ cp ../PkgE/conan.lock . # Do a copy of the lockfile
$ conan create PkgB/1.1@user/testing --lockfile
Copy link
Contributor

@lasote lasote Jul 9, 2019

Do the graph clean here?

The *conan.lock* file contains more information than the versions of the dependencies, it contains:

- The "effective" profile that has been used to compute this lockfile. The effective profile is the
combination of the profile files that could have been passed in the command line, pluse any
Copy link
Contributor

@lasote lasote Jul 9, 2019

Suggested change
combination of the profile files that could have been passed in the command line, pluse any
combination of the profile files that could have been passed in the command line, plus any

- The options values at each package. As downstream consumers can define options values, it is
important that this information is also stored, so it is also possible to build intermediate nodes
of the graph leading to the same result.
- Other kind of requirements like python_requires.
Copy link
Contributor

@lasote lasote Jul 9, 2019

Suggested change
- Other kind of requirements like python_requires.
- Another kind of requirements like python_requires.


This command will generate a *conan.lock* file. It behaves like :command:`conan install` command,
(this will also generate a lockfile by default), but without needing to actually install the
binaries, so it will be faster. In that regard it is equal to :command:`conan info` that can also
Copy link
Contributor

@lasote lasote Jul 9, 2019

Suggested change
binaries, so it will be faster. In that regard it is equal to :command:`conan info` that can also
binaries, so it will be faster. In that regard, it is equal to :command:`conan info` that can also


- :command:`conan graph build-order`

Takes a lockfile as argument, and return a list of lists indicating the order in which packages
Copy link
Contributor

@lasote lasote Jul 9, 2019

Suggested change
Takes a lockfile as argument, and return a list of lists indicating the order in which packages
Takes a lockfile as an argument, and return a list of lists indicating the order in which packages

One of the applications of lockfiles is to be able to propagate changes done in one package
belonging to a dependency graph downstream its affected consumers.

Lets say that we have the following scenario in which one developer does some changes to PkgB,
Copy link
Contributor

@lasote lasote Jul 9, 2019

Suggested change
Lets say that we have the following scenario in which one developer does some changes to PkgB,
Let's say that we have the following scenario in which one developer does some changes to PkgB,

.. image:: ../images/lockfile_ci_1.png

The next step is to know which dependants need to be built, because they are affected by the new
Copy link
Contributor

@lasote lasote Jul 9, 2019

Suggested change
The next step is to know which dependants need to be built, because they are affected by the new
The next step is to know which dependants need to be built because they are affected by the new

@lasote lasote merged commit 896b628 into conan-io:develop Jul 9, 2019
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants