First of all I’d want to thank you for your package. Looks very interesting. I just wanted to understand if it’s possible to publish it to pypi.
I’m investigating if I can use it my current project but an absence of the package on the pypi is a real blocker.
Have you faced some difficulties to publish it there or it’s just not your priority, and you’re mainly focusing on the conda?
Python modules are usually very easy to install, typically requiring nothing more that pip install <package> for basically any operating system. For graph-tool, however, the situation is different. This is because, in reality, graph-tool is a C++ library wrapped in Python, and it has many C++ dependencies such as Boost, CGAL and expat, which are not installable via Python-only package management systems such as pip. Because the module lives between the C++ and Python worlds, its installation is done more like a C++ library rather than a typical python module. This means it inherits some of the complexities common of the C++ world that some Python users do not expect.
I understand that it’s technically a wrapper for a C++ library. And I’ve checked the documentation before asking this question. Unfortunately the provided examples won’t allow to smoothly plug a library to the existing mature project (for example an installation of the debian package won’t provide with an access to the predefined virtual environment, and install it’s own python). Build from source is not a very good option too, as it will complexify automated processes like docker images builds, releases etc.
I don’t know all the potential problems for your library, and if you tried different approaches or not, so I’d like to ask about a few more details. Technically it’s possible to build a wheel package with required libraries backed in it. Or as an alternative, it could be published with the requirements to have C++ libraries already installed for a build during the pip installation (as it has been done for lxml, and a lot of other packages in the past (before starting using pre-built packages in the whl format).
I understand very well how pip wheel works, but I’m not going to go point by point why building a pip package is complicated with all these dependencies. The challenge is not to generate some pip wheel, but wheels that work for every platform, and of course maintaining the whole C++ stack that has to be included in it.
I’m aware of what is involved, but it is difficult to maintain this reliably, and in an automated way.
At the moment, the packages available are the ones listed in the website.
There’s no point having an abstract conversation about how it could be done in theory. If you think it’s straightforward, the best way to convince me is to do it yourself.
@tiago , It’s not an abstract conversation at least on my side. I asked about the plans and possible blockers. As I have no idea if you tested some of these approaches, and if you plan to extend the support.
Anyway, I see your point. I’ll check it on my own in this case.