conda-forge / vtk-feedstock

A conda-smithy repository for vtk.
BSD 3-Clause "New" or "Revised" License
13 stars 64 forks source link

OSMesa variant #40

Closed isuruf closed 7 years ago

isuruf commented 7 years ago

Fixes https://github.com/conda-forge/vtk-feedstock/issues/20

isuruf commented 7 years ago

@jakirkham, the linter failed. any idea why?

isuruf commented 7 years ago

This is ready for review now

conda-forge-linter commented 7 years ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

jakirkham commented 7 years ago

Not sure. Triggered the linter manually through the webhook. This likely goes back to our conversation earlier today.

Also have combined Python 2/3 in PR ( https://github.com/conda-forge/vtk-feedstock/pull/39 ) as well.

Korijn commented 7 years ago

Doesn't osmesa depend on llvm? Or is this the slower build?

Korijn commented 7 years ago

Also, shouldn't this variant have a different name? E.g. vtk-osmesa?

isuruf commented 7 years ago

Doesn't osmesa depend on llvm?

Yes. it pulls in llvm libraries

Or is this the slower build?

I'm not sure what you mean

Also, shouldn't this variant have a different name?

No need. installing vtk in an env withmesalib will install the vtk compiled with mesalib. If mesalib is not in the env, it will install the vtk compiled without mesalib

Korijn commented 7 years ago

I'm not sure what you mean

It's possible to build osmesa in a legacy mode without llvm, which has slower performance.

No need. installing vtk in an env withmesalib will install the vtk compiled with mesalib. If mesalib is not in the env, it will install the vtk compiled without mesalib

Doesn't that constitute a bug in conda? Shouldn't the latest build number always be preferred?

Don't get me wrong, I think it's clever! I just think this quirk in dependency resolution is not really meant to be used to pull in special flavours of packages.

If mesalib is not in the env, it will install the vtk compiled without mesalib

Why would conda prefer an older build of the vtk package? I don't get it. The newer build doesn't require mesalib; no problem, right? Why does the presence of mesalib suddenly change that?

isuruf commented 7 years ago

This is what conda features are there for. From https://conda.io/docs/user-guide/tasks/build-packages/features.html

"Think of features as belonging to the environment the package is installed into, not the package itself. When a feature is installed, conda automatically changes to a package with that feature if it exists. For example, when the mkl feature is installed, regular NumPy is removed and the NumPy package with the mkl feature is installed. Enabling a feature does not install any packages that are not already installed, but all future packages with that feature that are installed into that environment will be preferred."

Doesn't that constitute a bug in conda? Shouldn't the latest build number always be preferred?

As it says in the above doc, it's not a bug. It's the intended behaviour of conda. conda would prefer a package with the feature over a package without the feature if that feature is activated in the environment

Korijn commented 7 years ago

:bulb: Thank you for elaborating. It makes sense now.

isuruf commented 7 years ago

CI is finished now

philippjfr commented 5 years ago

No need. installing vtk in an env withmesalib will install the vtk compiled with mesalib. If mesalib is not in the env, it will install the vtk compiled without mesalib

Sorry to add noise here but I just wanted to clarify, if you install mesalib and vtk in the same conda install invocation will this still resolve correctly?