Sorry, should have said to install it into a new environment, or yeah a clone. I (obviously) haven’t tested it much with other packages yet. Glad you recovered. If you hadn’t come across it there’s also conda list --revisions
which will show environment changes and conda install --revision N
which lets you ‘rollback’ (I believe it just does reversed install/removes so won’t help if something plays badly but hopefully would have worked there).
Not quite sure what caused that but would assume some dependent package of the py37 variant that another package didn’t like and the best (or first at least) config they could agree on was a rollback to py36. An unfortunate side effect of running a full SAT solver in a package manager.
Can you do a conda list --explicit > spec-file.txt
and send me that so I can test against it and hopefully sort out what’s happening. Or at least have it play nice so it won’t hose your environment next time
I copied over a recipe that specified particular versions of dependencies, but looking at other pillow recipes I don’t think it is that particular and another recipe (either conda-forge or anaconda) just specified package without versions. So I’ll try that. That is at build time and they’ll still be partially fixed at run but if I’m selecting a non-standard version that should resolve it. Otherwise I’ll have to track down the conflict.
I wan’t yet considering pip support. I’d tend to think the current method of compiling it for the machine is best there given the lack of system package management. You can build a wheel from conda but not sure how that’d work with the various non-python dynamic linkages. I’ll have a look at that but was only really looking at conda support at the moment.
Tom.