Mário Costa
2018-10-16 11:23:29 UTC
Hi, I'm new to conda, already managed to contribute for some packages of
the ecosystem, but there's are some things that are still not clear to me,
and I have not been able to understand so far (reading docs and such).
1- Conda forge packages after conda-smithy 3, and conda-build 3, started
using a new pinning mechanism that is not hardcoded in the meta.yaml
recipe. Now, from what I've understand, conda-forge-pinning package
contains a snapshot of configuration for new builds, referencing official
pinned conda-forge packages.
1.1 - What it is no clear to me, if some of our dependencies have a
different version from conda-forge-pinning, how do we solve that ? we do
not use conda-forge-pinning package, and use instead a custom conda_build_config.yaml,
in the recipe directory ?
1.2 - If we want to upgrade a new package in conda-forge and create a pull
request, and this package requires a higher version of one package in the
conda-forge-pinning, how does conda, keep track of different snapshots ?
How can I have a say, conda-forge-pinning with a dlib 2.26, and another
with a dlib 2.58, and refer to a different one if I'm building say qt 5.6
or the other for qt 5.11 ?
1.3 - Also, in this specific case, dlib, is provided in linux host
environment, but with an undesirable low version, 2.26, how do I state in a
recipe that I do not want to use the host version, but instead want to use
a conda-forge or anaconda version ? Wont this conflict with the OS dlib at
linking time ?
the ecosystem, but there's are some things that are still not clear to me,
and I have not been able to understand so far (reading docs and such).
1- Conda forge packages after conda-smithy 3, and conda-build 3, started
using a new pinning mechanism that is not hardcoded in the meta.yaml
recipe. Now, from what I've understand, conda-forge-pinning package
contains a snapshot of configuration for new builds, referencing official
pinned conda-forge packages.
1.1 - What it is no clear to me, if some of our dependencies have a
different version from conda-forge-pinning, how do we solve that ? we do
not use conda-forge-pinning package, and use instead a custom conda_build_config.yaml,
in the recipe directory ?
1.2 - If we want to upgrade a new package in conda-forge and create a pull
request, and this package requires a higher version of one package in the
conda-forge-pinning, how does conda, keep track of different snapshots ?
How can I have a say, conda-forge-pinning with a dlib 2.26, and another
with a dlib 2.58, and refer to a different one if I'm building say qt 5.6
or the other for qt 5.11 ?
1.3 - Also, in this specific case, dlib, is provided in linux host
environment, but with an undesirable low version, 2.26, how do I state in a
recipe that I do not want to use the host version, but instead want to use
a conda-forge or anaconda version ? Wont this conflict with the OS dlib at
linking time ?
--
You received this message because you are subscribed to the Google Groups "conda - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to conda+***@continuum.io.
To post to this group, send email to ***@continuum.io.
Visit this group at https://groups.google.com/a/continuum.io/group/conda/.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/conda/8a3825fb-cbb4-4354-a3cd-7c63bc4d0581%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.
You received this message because you are subscribed to the Google Groups "conda - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to conda+***@continuum.io.
To post to this group, send email to ***@continuum.io.
Visit this group at https://groups.google.com/a/continuum.io/group/conda/.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/conda/8a3825fb-cbb4-4354-a3cd-7c63bc4d0581%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.