Different Python build vs test (if Python not explicitly listed) #835
Comments
|
Fundamentally, the issue is that recipes that depend on numpy should always list their python dependency explicitly. (This is a reasonable requirement because that is actually how the true dependency graph should look for such programs.) All programs that depend on python should explicitly state the version of python they use via: requirements:
build:
- python {{PY_VER}}*
run:
- python {{PY_VER}}*But if you're sloppy about it, However, that special case logic only checks your top-level requirements. It doesn't look at the full set of dependencies after the solver has been executed. IMHO, I think attempting to handle the general case would make this special case logic even uglier than it already is. Since it's technically an error (logically) not to mention |
|
Having an error here seems reasonable. Though I picked |
Hmm, that's a good point. I'm not sure what right option is here. I mean, at the end of the day, conda-build doesn't have AI: It can't tell you what your requirements list should say in the general case. But there are a lot of little examples like this where we could tell the user on a case-by-case basis that we think he's doing it wrong. One big temptation -- and a big mistake -- would be for conda-build to "help the user out" by silently "fixing" his recipe or inferring extra semantics when we think he left something out. (An example of this is how conda will pick a version of python for you (2 vs 3) if you don't specify one explicitly. It definitely encourages violations of "explicit is better than implicit".) Once such special-case logic is added to conda, it can never be removed, because recipes will be written to depend on it (perhaps unknowingly). A better way to handle bad recipes would be to have a special module in conda-build that serves as a "linter" for recipes to tell users what mistakes they've made. Then, instead of trying to support one special case after another in the conda code base, the world will simply be populated with well-formed recipes. If we ever decide to relax a linter rule, no problem: just remove or edit the rule. Existing packages will continue to have the same semantics that they always had. What do you think? |
|
Definitely agree that more of these quiet changes should be turned into errors, but there probably should be a phase out (warning/deprecation period) first. I think I agree with having a linter ( Having this logic in |
|
Not sure how to implement that. If I got it right the linter must know the python dependencies for each package before inspecting the recipes for that to work, right?
Maybe conda-build should just raise an instead of trying to help 😉 |
|
So, to be clear. This is not a totally theoretical issue as it can cause problems when building on Windows. |
Apparently packages depending on numpy should always list their python dependency explicitly: conda/conda-build#835 This fixes the build for another version than the default version in conda-build.
apparently packages that depend on numpy should always list their python dependency explicitly: conda/conda-build#835 this fixes the build for another python version: ```conda build --python 3.4 python/nlopt```
Apparently packages depending on numpy should always list their python dependency explicitly: conda/conda-build#835
Apparently packages depending on numpy should always list their python dependency explicitly: conda/conda-build#835
apparently packages that depend on numpy should always list their python dependency explicitly: conda/conda-build#835 this fixes the build for another python version: ```conda build --python 3.4 python/nlopt```
apparently packages that depend on numpy should always list their python dependency explicitly: conda/conda-build#835 this fixes the build for another python version: ```conda build --python 3.4 python/nlopt```
|
@jakirkham @msarahan I think this is related to the problems we've been seeing over at conda-forge. Though not related to numpy in this case. If you build a package that does not explicitly require Python, but you are activating features (such as will print |
apparently packages that depend on numpy should always list their python dependency explicitly: conda/conda-build#835 this fixes the build for another python version: ```conda build --python 3.4 python/nlopt```
|
So, I have been thinking about this a bit more and basically the bug is simply a failure to identify the transitive property of packages. Namely if I depend on things that depend on cc @isuruf |
|
I just hit this again in the vitables-feedstock: conda-forge/vitables-feedstock#10 |
|
Hi there, thank you for your contribution! This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs. If you would like this issue to remain open please:
NOTE: If this issue was closed prematurely, please leave a comment. Thanks! |
github-actions
bot
added
the
stale::closed
If I have a recipe for a package that consist of the
meta.yamland some simple build scripts, it turns out the python used for the build and test will be different.Here is the build result. Note that it used Python 2.7 for the build and Python 3.5 for the testing phase. Also, note that the final package does not depend on Python (or its version) even though it is an implicit dependency (via
numpy).Explicitly stating Python is a dependency or uncommenting the lines above results in the same Python version being used (2.7 in this case).
Build system information.
The text was updated successfully, but these errors were encountered: