Add LibSVM

[patricksnape]

@183amir Asked me to take over this PR ( #352 ). So I have squashed a bunch of commits and re-added this PR. This should hopefully work on all platforms.

[patricksnape]

@msarahan this became a bit confusing but this is now the libsvm PR. I point you again to this, which was required to get builds to work and appears to be the source of the woes on the jpeg PR.

[183amir]

Thank you @patricksnape. Now you can easily test your windows builds here without waiting for me. Also, thanks for fixing the Unix builds too; that's exactly how I imagined it :)

[183amir]

Could you please add if errorlevel 1 exit 1 here too?

[conda-forge-admin]

Hi! This is the friendly conda-forge-admin automated user.

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

[183amir]

@patricksnape could you please modify your test section back to this:

+test:
+  requires:
+    - python {{ environ['PY_VER'] + '*' }}                    # [win]

and see it will work again? but do not remove Python from build requirements.

[patricksnape]

@183amir That works as well. I have tested that before. The issue is that this logic that we can just place it in build and test is not correct because the Python version doesn't seem to propagate properly into the test environment without PY_VER.

[183amir]

Could you explain further? What do you mean by saying it doesn't propagate?

[patricksnape]

Previously it seems the wisdom was that you just turned the features on and then placed python in the build requirements to ensure that the features were activated. But it appears that people may have been doing this without running any tests, and therefore never ran into the fact that the latest conda-build will fail with conflicts. Therefore, I tried adding python as a test requirement, which should, by the previous logic, also activate the features. But it doesn't because for some reason having python in test but not in run causes conda build to just use whatever python version the root environment is. Which is also obviously incorrect. So really this looks to me like its just a bug, and that you should only need to add it to the test requirements and the version should be properly picked up as it is in the run requirements.

[jakirkham]

If we can switch back to using environ['PY_VER'] here, but leave everything else alone (including build requirements) and CI passes. I would happily merge this. Thanks for trying this out here so that we can see this doesn't work.

[183amir]

I think what conda is doing is logically correct. You want to build libsvm in a way that is compatible with Python at runtime. Each Python has a different runtime (visual studio runtime). Also, the Python package tracks the runtime feature.
So what you want is to have 3 DIFFERENT packages of libsvm on windows for each Python 2.7, 3.4, and 3.5.
So try adding Python to requirements:run and we will have 3 different libsvm compiled with a compatible runtime.
Remember that when you are using a feature in conda builds, you should also depend on the package that tracks that feature both during build and run. Unfortunately, python is the package that tracks the vc features. Then, I think you should add it in both build and run requirements and just remove it from test.

[patricksnape]

@183amir Yes but that is not what we have been saying in all the other recipes. We have not been pinning builds Python that do not require Python. If that is what we decide to do then so be it, but I would prefer something like what @jakirkham was suggesting with a proper metapackage used for building.

[jakirkham]

Yeah, I don't know about conda doing the right thing here. We have seen this problem with test requirements misbehaving on Windows in lots of places. Though I'm not sure that a bug in conda is really the whole problem.

Adding it to run requirements may help, but it just feels wrong. Why is that we must depend on Python for non-Python things? Also, we haven't needed to do this before. We need a better way to track this in Windows.

Though if you want to raise this issue on the website issue tracker that seems perfectly fine to me. We do need a better way to fix this. The problem we are seeing here is hardly unique and deserves discussion with the larger community.

[183amir]

@jakirkham I would not merge this like this. Because I think you will have the same error when you try to actually install the package.

[patricksnape]

@183amir It will only fail if you try to install it into an environment where there are no vc* features activated. This may be the case for something like an R environment, but it will not be the case in any Windows Python environment. Therefore, it will always install. If it depended on Python and you had an R only environment, your environment would end up getting polluted with Python anyway (if it had the python runtime requirement).

[jakirkham]

I would not merge this like this. Because I think you will the same error when you try to actually install the package.

Have you run into this issue when trying to install, @patricksnape? If you have, we should probably make it a run requirement (as undesirable as it is). If not, then I think we should just chalk this up as another case where test requirements with conda has a bug. Admittedly this one is a little weirder, but it still feels like the same ilk of problems we have seen before.

[patricksnape]

@jakirkham To be honest, I'm pretty pragmatic about this. If everyone is happier with the 100% works but is ugly "add to the run requirements" way - then I will change it to that. We can always revisit when conda build sorts itself out.

[183amir]

I don't get it. How are you ensuring that 3 different libsvm packages are built? Don't we need 3 different libsvm packages?

[jakirkham]

To be honest, I'm pretty pragmatic about this. If everyone is happier with the 100% works but is ugly "add to the run requirements" way - then I will change it to that. We can always revisit when conda build sorts itself out.

Ok, I will leave it up to your discretion, @patricksnape . Personally, I am happy with how it is now.

I don't get it. How are ensuring that 3 different libsvm packages are built? Don't we need 3 different libsvm packages?

We are. Take a look at the builds on AppVeyor and you will see this is the case. It is just getting really messed up setting up the testing environment correctly.

[183amir]

@jakirkham can't we add a meta package in conda-forge let's say called vc-feature and track the vc features in there? Then, we can add that package to run and build requirements?

[jakirkham]

...can't we add a meta package in conda-forge let's say called vc-feature and track the vc features in there? Then, we can add that package to run and build requirements?

That's what I was thinking earlier too. This really seems like a nice way to go as we can use it to properly effect these sorts of changes.

[jakirkham]

^ I should add this is a variant based on a suggestion that @pelson made a couple of weeks back.

[patricksnape]

Just did a test install locally (in a new environment) and it seems fine to me. So I think this is good as is unless this actually ends up being a problem. Then, if we get that metapackage we can update the feedstock. If it ends up being broken when other packages rely on it somehow then I apologize and at least we learnt something concrete about the resolution system.

[jakirkham]

Good enough for me. Satisfied, @183amir?

[183amir]

I went ahead and created that meta-package (#363). But if this is working and you are ok with it, I'm satisfied.

[jakirkham]

Thanks for getting the ball rolling on that @183amir. I added a few comments. Once we get something like that rolling, we will likely want to substituted the Python stuff out of everything that uses it on Windows anyways.

[jakirkham]

Thanks everyone for helping get this in tip top shape.