[docs] fix RTD builds due to conda's problems #2725
Conversation
| /home/docs/.conda/bin/conda install -q -y -n r_env -c conda-forge \ | ||
| r-pkgdown=1.3.0=r351h6115d3f_1000 \ | ||
| r-pkgdown=1.3.0=r35h6115d3f_1001 \ |
There was a problem hiding this comment.
@StrikerRUS what if we just removed build numbers and did r-pkgdown=1.3.0? Won't we have to fix this again if the RTD build machines change?
There was a problem hiding this comment.
It may fail. In some cases even builds are important and with one number everything is OK, while with another one build crashes.
Sorry, I didn't get it: how RTD build machines are related to conda packages build numbers?
There was a problem hiding this comment.
That string has some extra details in it that some packages use for builds that used, say, specific compilers for creation.
From conda docs:
Differentiates builds of packages with otherwise identical names and versions, such as:
- A build with other dependencies, such as Python 3.4 instead of Python 2.7.
- A bug fix in the build process.
- Some different optional dependencies, such as MKL versus ATLAS linkage.
Nothing in conda actually inspects the build string. Strings such as np18py34_1 are designed only for human readability and conda never parses them.
I've found in the past that my conda env files are not portable across operating systems until I remove those.
This is why conda env export ships with the argument --no-builds, so you can build a conda environment file on one machine and feel confident it will work on others
There was a problem hiding this comment.
Usually build number increment indicates bug fixes (for packaging bugs):
https://github.com/conda-forge/r-pkgdown-feedstock#updating-r-pkgdown-feedstock
In order to produce a uniquely identifiable distribution:
If the version of a package is not being increased, please add or increase the build/number.
If the version of a package is being increased, please remember to return the build/number back to 0.
There was a problem hiding this comment.
I see, ok guess I misunderstood. Thanks
There was a problem hiding this comment.
From the link you have provided above:
| build_number | integer | A non-negative integer representing the build number of the package. Unlike the build string, the build_number is inspected by conda. Conda uses it to sort packages that have otherwise identical names and versions to determine the latest one. This is important because new builds that contain bug fixes for the way a package is built may be added to a repository. |
|---|
There was a problem hiding this comment.
Despite that it seems we talked about different "build numbers" (you about build, me - build_number) and I have no idea how to specify build_number without build string, I guess you were confused by the world "inspects".
Nothing in conda actually inspects the build string.
Maybe conda doesn't inspect build strings, it compares them for sure. Otherwise, the following example will not work:
The build string constraint
"numpy=1.11.2=*nomkl*"matches the NumPy 1.11.2 packages without MKL but not the normal MKL NumPy 1.11.2 packages.
https://docs.conda.io/projects/conda-build/en/latest/resources/package-spec.html#examples
Package dependencies are specified using a match specification. A match specification is a space-separated string of 1, 2, or 3 parts:
...
The third part is always the exact build string. When there are 3 parts, the second part must be the exact version.
https://docs.conda.io/projects/conda-build/en/latest/resources/package-spec.html#package-match-specifications
Also, refer to #2688 (comment).
Versions were taken from an accidental successful build: https://readthedocs.org/api/v2/build/10331271.txt.