Conda package

[1ace]

What language and solver does this apply to?
Python

Describe the problem you are trying to solve.
It is currently impossible to depend on a pip package from a conda package, making it impossible to use or-tools in anything that is published as a conda package.

Describe the solution you'd like
Publishing a conda package for or-tools would fix all the issues :)
A lot of the work has already been done and is available on conda-forge/staged-recipes#2878

Additional context
Issue #92 talked about this already, but was closed because there's a hacky way for users to locally workaround this issue that might work if all the python pacakges versions (and stars) are aligned (which is likely not often the case), but this is irrelevant anyway as that doesn't work for anyone publishing a package; that hack only works for someone doing something with or-tools just on their machine and not sharing it with anyone, which excludes all the tools/libs that use or-tools.

---

I hope that enough time has passed for the maintainers of this project to reconsider providing a conda package 🙂

[lperron]

Last time we had this discussion, there was a simple process to transform a pypi package into a conda one.
Isn't it the case anymore ?

[1ace]

I'll invite you to read the message above where I already explained why that reasoning is entirely missing the point of package managers instead of just doing local installs 😉

If there's something specific you don't understand feel free to ask a question about that.

Side note: I was hoping the maintainer would've changed since last time; do you have a colleague who is more familiar with package managers who could weigh in on this discussion instead?

[lperron]

I am the owner of or-tools. I will welcome contrib, but I have no time to look at conda. Our priorities in the build process are maven, then homebrew, then getting rid of make. Conda comes after that. Le sam. 12 sept. 2020 à 18:49, Eric Engestrom <[email protected]> a écrit :

…

I'll invite you to read the message above where I already explained why that reasoning is entirely missing the point of package managers instead of just doing local installs 😉 If there's something specific you don't understand feel free to ask a question about that. Side note: I was hoping the maintainer would've changed since last time; do you have a colleague who is more familiar with package managers who could weigh in on this discussion instead? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3LJKZ6L6AXLDW2OVBTSFORA3ANCNFSM4RHMKCEQ> .

[Mizux]

In any order:

1. You should use the CMake based build instead, it is intended to works nicely with any distro package manager or distro generator like Yocto and as Laurent said Make based build is legacy...
   e.g. this C++ package for the homebrew project with all third party provided by others formulae https://github.com/Mizux/homebrew-or-tools (hope to integrate it in hombrew-core once release 8.0 is out)

2. You'll need conda-forge to provide an abseil-cpp package built using the C++17 standard revision !!!

3. Coin-OR in conda-forge is still not ready -> help anaconda community to fix all ortools deps first ;)
   see: Add coin or split packages conda-forge/staged-recipes#12249

4. Pip is shipped with any recent python distribution

   pip is the preferred installer program. Starting with Python 3.4, it is included by default with the Python binary installers.

   ref: https://docs.python.org/3/installing/index.html?highlight=pip#key-terms

5. Pypi is sponsored by the Python Software Foundation itself while anaconda is a private company...
   ref: https://pypi.org/sponsor/

6. Anaconda use the glibc only so we are losing the Alpine and FreeBSD (IIRC) users which are using libmusl...

7. Since you have the source you can create the package you want (with the packager you want), simply modify the package_python target. (you can even have a patch on top of ortools in your conda recipe)

8. We are using the official manylinux2010 docker image to generate the packages...

9. IMHO, the main problem anaconda try to solve is when using native packages since Python interpreter load everything in the same process instead of sandboxing them in subprocess (i.e. it's a python design flaw IMHO) but:
   9.1 PEP 513 impose each packages to embed all third parties, so depending on system package is formally forbidden...
   9.2 But any distro maintainer can choose to do it, thus now you can see thousands of python packages directly integrated to most distro so you could solve this kind of problem easily since you "own" all packages and you don't need to use an external package manager like anaconda, I feel it more FOSS friendly to do it at a distro level or distro/image generator level (ed like Yocto)...
   9.3 you could also build everything from source and generate a container image to "fix" this kind of issue...

10. Should we build the ortools package with SCIP enabled i.e. what is the equivalent of the The Debian Free Software Guidelines (DFSG) (ed also used by the homebrew project) for conda-forge ?

So all in all, we will never "migrate" to anaconda and drop our wheel package flow, BUT we are open to add stuff for an anaconda workflow using the CMake based build if you are currently "blocked" by our choices...

[saguerraty]

Hi there, is there any update on this?
I'm facing the same issue as @1ace describes :)

[lperron]

As Corentin said, we will not work on Conda, but accept patches. Le dim. 25 avr. 2021 à 06:35, Sebastian Guerraty ***@***.***> a écrit :

…

Hi there, is there any update on this? I'm facing the same issue as @1ace <https://github.com/1ace> describes :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3JS3GZ76KKK5AJPEYTTKOLZVANCNFSM4RHMKCEQ> .

[BastianZim]

Just as an FYI, we have a new conda-forge PR in conda-forge/staged-recipes#16147