-
Notifications
You must be signed in to change notification settings - Fork 383
warnings for local-recipes-index #4297
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
base: develop2
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -18,6 +18,26 @@ This setup is particularly useful for: | |
| :ref:`setup_local_recipes_index`. | ||
|
|
||
|
|
||
| .. warning:: | ||
|
|
||
| Using the ``local-recipes-index`` feature from a fork of ``conan-center-index`` Github repository, | ||
| without using a package server or relying on the ConanCenter package server can easily result in | ||
| missing dependencies due to old versions being removed by upstream ``conan-center-index``. The | ||
| recommendations are: | ||
|
|
||
| - Use a package server to store your recipes and binaries built from your fork, and use it to resolve | ||
| dependencies. | ||
|
Comment on lines
+28
to
+29
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since it is not possible to upload binary packages to a remote without also uploading the recipes, I would probably just leave this whole section out, as it essential boils down to "if you need binaries, you need a server" therefore, using local-recipes-index AND needing to configure a remote, it is not entirely clear in which scenario |
||
| - If not using a package server, at least consider adding ``conancenter`` as remote besides your | ||
| ``local-recipes-index``, possibly with the ``recipes-only`` argument enabled, to be able to fetch | ||
| those older versions removed from the source from it. | ||
| - If you are not using a server, then it becomes necessary to move forward with the ``local-recipes-index`` | ||
| source repository. If a version is removed, the requirements to that old version must be updated to | ||
| existing versions. | ||
| - Another alternative is managing your fork accordingly, to avoid removals, not merging from upstream, | ||
| applying only selective patches. | ||
|
|
||
|
|
||
|
|
||
| Building Binaries from a private `conan-center-index` fork | ||
| ---------------------------------------------------------- | ||
|
|
||
|
|
@@ -229,8 +249,9 @@ Several important points should be considered when using this new feature: | |
| packages for regular use. | ||
|
|
||
| - Also, note that a server remote can retain a history of changes storing multiple recipe | ||
| revisions. In contrast, a `local-recipes-index` remote can only represent a single | ||
| snapshot at any given time. | ||
| versions and revisions. In contrast, a `local-recipes-index` remote can only represent a single | ||
| snapshot at any given time. That means that it will be impossible to use or resolve to older | ||
| recipe revisions or to old versions that have been removed from the source repository. | ||
|
|
||
| - ConanCenter does not use ``python-requires``, as this is a mechanism more intended for | ||
| first-party packages. Using ``python-requires`` in a ``local-recipes-index`` repository | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would probably tweak wording to make it more "generic" in terms of explaining the pitfalls, but more specific in terms of what happens with Conan Center.
Some suggestions:
conan-center-index's main purpose is to feed into theconancenterremote, and the ability to use it as a local-recipes-index is not a goal.conan-center-index, users must be careful in the two following scenarios:git pull,git merge master,git rebase masteretc) - because versions they rely on may no longer be exportable from master. Here the best mitigation is just to ensure the versions needed by the user are always in the repo, for example, they can always add their versions to a different subfolder (e.g. something other than "all") - which will minimise merge conflicts as the only potential change is "config.yml" in this scenarioconancenterremote alongside local-recipes-index, you have two repositories that potentially export the same versions. This may be intentional or not - users need exercise care.