python-jgrapht release candidate

[Dimitrios Michail]

Hi guys, 

I created a first release candidate of the python-jgrapht package! 

The version is 1.4.1.0rc1. I decided to follow the JGraphT version with an extra .x version at the end. The `rc1` will go away after the official release. 

I am, however, building against the 1.4.1-SNAPSHOT, since it contains some important bugfixes (especially the one with the vertex providers at the I/O package). It actually makes sense (and I would be in favor of) to release 1.4.1 with our current codebase, possibly including #920. 

Regarding the python package, I am still missing the windows build, but linux (3.6, 3.7 and 3.8 with a very old glibc version are there) and macosx (3.6, 3.7 and 3.8 with sdk 10_13). All these are x64, since graalvm does not support i686 which means that we cannot build 32-bit packages.

Could you have a look and provide some feedback? 

The project is located at https://pypi.org/project/python-jgrapht . 

You can install using `pip install python-jgrapht`. Just make sure you have a recent version of pip installed (`pip --upgrade install pip`).

Afterwards

```

import jgrapht

g = jgrapht.create_graph()

```

The graph api is almost identical with our Java one. 

Full docs (with tutorial, api, examples, etc) are available at  https://python-jgrapht.readthedocs.io/ . 

The test coverage is also quite high. I run tests both on the c-api project and on the python one. Nevertheless, 

some bug might have gotten in. I would appreciate if you could play around with it a bit. 

Best regards, 

Dimitrios

[John Sichi]

I've been attempting to install, but haven't been successful so far due to the need to keep installing more tools.  My expectation from the doc was that to simply install the package, I shouldn't need any build tools, but actually I need cmake, maven, native-packager, etc.

I'll keep installing tools and let you know how it goes.

[John Sichi]

After installing all the tools, I was able to install successfully and run an example fine.  Great work!

In a few places in the docs, there are statements like "In JGraphT both the vertices and the edges of the graph are represented using integers".  In places like these, I think it's important to distinguish "JGraphT" vs "the Python bindings for JGraphT', otherwise someone randomly coming across the page via a Google search might not realize the difference.  In cases where the functionality is identical, there's no need for the distinction.

Have you thought about how you'd like to handle keeping everything in sync across the projects?  Our deprecation policy should help a lot, since we'll catch breakage when the capi is built.  Will the burden of the fix be on the person making the change in the Java codebase?  Or will there be a dedicated non-Java maintainer?

Likewise, when new functionality is added on the Java side, ideally the contributor would create a corresponding issue on the non-Java side to get it added there as well.

I would definitely be in favor of a 1.4.1 release.  I'd also like to re-suggest that the capi and jgrapht-python repositories should live under the jgrapht github org to make the relationship officially close.  If you think it's too early for PR's etc, you'd be free to define whatever policies you want for how the code gets maintained in those repos (and who is allowed to commit).

[Dimitrios Michail]

On Friday, May 29, 2020 at 7:33:01 AM UTC+3, John Sichi wrote:

After installing all the tools, I was able to install successfully and run an example fine.  Great work!

What kind of system are you using? Maybe try updating the pip version first `pip install pip --upgrade`. With an old version of pip, it tries to build the package. 

Is some wheel package from `https://pypi.org/project/jgrapht/#files` compatible?  Try with `pip install wheelfile`. 

Let me know how to update the installation guide, so that people actually succeed in installing the wheels. Otherwise, no one is going to use this.

I would guess, that if you first do a `pip install pip --upgrade`, then `pip install jgrapht` should work!

 

In a few places in the docs, there are statements like "In JGraphT both the vertices and the edges of the graph are represented using integers".  In places like these, I think it's important to distinguish "JGraphT" vs "the Python bindings for JGraphT', otherwise someone randomly coming across the page via a Google search might not realize the difference.  In cases where the functionality is identical, there's no need for the distinction.

Yes you are right, I will change that.  

Have you thought about how you'd like to handle keeping everything in sync across the projects?  Our deprecation policy should help a lot, since we'll catch breakage when the capi is built.  Will the burden of the fix be on the person making the change in the Java codebase?  Or will there be a dedicated non-Java maintainer?

The python-jgrapht has a git submodule dependency on the jgrapht-capi project. This dependency is with the git commit id, which means that it is stable, even if JGraphT or the jgrapht-capi changes. The capi on the other hand, will need to be updated across versions, as you suggest.

Likewise, when new functionality is added on the Java side, ideally the contributor would create a corresponding issue on the non-Java side to get it added there as well.

Is it probably too much to ask someone to also add the capi and the python bindings stuff.  I will probably do it at the beginning. I am still missing a few algorithms, like drawing and capacitated MSTs. 

Most of the patterns that might occur (like a result which is a vertex set, etc.) are already handled, so the procedure is mostly copy-paste, and of course keeping a strict naming scheme.

I would definitely be in favor of a 1.4.1 release.  I'd also like to re-suggest that the capi and jgrapht-python repositories should live under the jgrapht github org to make the relationship officially close.  If you think it's too early for PR's etc, you'd be free to define whatever policies you want for how the code gets maintained in those repos (and who is allowed to commit).

I do not mind putting them in the jgrapht organization. While I understand the PR policy for one time contributors, in my case it just slows me down. I need to add features and fix bugs quickly.

Best, 

Dimitrios

[Joris Kinable]

I'm not very fluent with the python eco system. Need some help:

(venv) kinable@udc4d41d1366a5b:~/workspace/research/external/jgrapht/python$ sudo -H pip install --user jgrapht
Collecting jgrapht
  Downloading jgrapht-1.4.1.0rc1-cp36-cp36m-manylinux2010_x86_64.whl (9.7 MB)
     |████████████████████████████████| 9.7 MB 1.2 MB/s
Installing collected packages: jgrapht
Successfully installed jgrapht-1.4.1.0rc1
(venv) kinable@udc4d41d1366a5b:~/workspace/research/external/jgrapht/python$ python3 plot_enumerate_cliques.py
Traceback (most recent call last):
  File "plot_enumerate_cliques.py", line 16, in <module>
    import jgrapht
ModuleNotFoundError: No module named 'jgrapht'

Any suggestions?

--
You received this message because you are subscribed to the Google Groups "jgrapht-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jgrapht-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jgrapht-dev/1ab67d9e-89f3-40f8-86d1-ab48f4e3eac1%40googlegroups.com.

[Dimitrios Michail]

Hi Joris, 

if you need to write python3, then also pip should be pip3. You probably have both 2.7 and 3.x python versions.

The `pip` command installs for the 2.7 version. 

The easiest in older systems which have both python versions, is to use the venv module of python 3. 

```

python3 -m venv venv

```

This creates a folder called `venv` with a new python3 installation.

You activate using

```

source venv/bin/activate

```

Now you are in a virtual environment which have python3 by default. 

```

pip install pip --upgrade

pip install jgrapht

```

Then 

```

python -c 'import jgrapht; print(jgrapht.__version__);'

```

should print `1.4.1.0rc1`.

Best, 

Dimitrios

[Dimitrios Michail]

Another option of course is to replace `pip` with `pip3`. 

You might still need to upgrade it to newer versions.

To unsubscribe from this group and stop receiving emails from it, send an email to jgrapht-dev+unsubscribe@googlegroups.com.

[Joris Kinable]

Perfect, works like a charm! The crux was to upgrade pip after activating the venv, not before. I was able to run all the tutorials.

Do you think there will be a way to associate data with edges/vertices? This, in my opinion, is one of the strong suits of JGraphT in Java. In your previous email you mentioned some of the technical challenges. Would a solution like networkx be possible where you have edge/vertex 'data'?

Are there any essential merges prior to releasing 1.4.1?

Joris

[Dimitrios Michail]

On Fri, May 29, 2020 at 9:24 AM Joris Kinable <j.ki...@gmail.com> wrote:

Perfect, works like a charm! The crux was to upgrade pip after activating the venv, not before. I was able to run all the tutorials.

Yes, for some reason pip needs to be updated. Probably John hit the same issue. I updated the installation guide on the docs.  

Do you think there will be a way to associate data with edges/vertices? This, in my opinion, is one of the strong suits of JGraphT in Java. In your previous email you mentioned some of the technical challenges. Would a solution like networkx be possible where you have edge/vertex 'data'?

I fixed the vertices/edges to integers, otherwise there are going to be tons of problems when crossing the python-java boundary. Imagine if you have to define vertex suppliers in python. I already did some scary stuff for importers/exporters in order to be able to call python functions from the java world.  The result is not pretty, but all importers/exporters support vertex and edge attributes.

On the other hand, you are right, it might make sense to give a more user-friendly environment like networkx. However, this can be done directly in python.

We could for example create another graph class which presents to the user a more user-friendly view. Maybe 

vertices and edges are objects (essentially wrapping the integer identifier) and perhaps like networkx provide some 

dictionary like access to the vertex and edge attributes.

Are there any essential merges prior to releasing 1.4.1?

Maybe #926. Timofey tracks this. 

Best, 

Dimitrios

To view this discussion on the web visit https://groups.google.com/d/msgid/jgrapht-dev/CAPEkHr6W7JwDhJmzNCbQ53iUp4YP7smFNMW_sN7OmDTh%3D_ca4w%40mail.gmail.com.

[Dimitrios Michail]

For some reason if you use pip <=18 it tries to install from source. If you have >=19 then it finds the wheels. 

This needs some extra investigation. 

[Тимофей Чудаков]

Hi Dimitrios,

I installed and tested the package a bit. The graph manipulation related methods work fine. But unfortunately, I can't access any algorithms in the jgrapht.algorithms subpackage. However, I can access jgraph.metrics, jgrapht.generators, etc. I guess the reason is that objects from files under jgraph/* are imported, but the files from the subdirectories are not. 

I'm running Python 3.6.9 on Linux. 

Best regards,

Tymofii Chudakov

To view this discussion on the web visit https://groups.google.com/d/msgid/jgrapht-dev/CAJu0w4z-3CAPQE0HKgEpyAON1aCSY96NNddY%2Bd9TD%3DD-aRMUGg%40mail.gmail.com.

[Dimitrios Michail]

Hi Timofey, 

thanks for the feedback. 

I have not imported them automatically. You can access them if you write something like 

```

import jgrapht.algorithms.cliques

```

then `jgrapht.algorithms.cliques.bron_kerbosch_with_degeneracy_ordering(g)`

or 

```

import jgrapht.algorithms.cliques as cliques

```

then `cliques.bron_kerbosch_with_degeneracy_ordering()`. 

Do you think I should automatically import stuff in other modules?

I do not want to automatically import all methods in the `jgrapht.algorithms`. Maybe if I just import

all submodules in the `jgrapht.algorithms` but not the methods.

Regards, 

Dimitrios

[Тимофей Чудаков]

Heh, I think I just forgot that I can import files from subfolders using `from jgrapht.algorithms import planar`. Most Python libraries don't import the submodules recursively, so I don't think there's a reason to do it in this case. 

[Dimitrios Michail]

Just for debugging purposes, could you send me the output of 

```

python -c "import pip._internal; print(pip._internal.pep425tags.get_supported())"

```

I think the problem is that your pip is version 18 or older and it does not support the manylinux2010 builds but only manylinux1. 

We could add a build using manylinux1 but this is a CentOS 5 machine which is already way way old.

The good news, is that you managed to actually build it from source   :-)

On Friday, May 29, 2020 at 7:33:01 AM UTC+3, John Sichi wrote:

[John Sichi]

Your debugging command failed because it said module pip._internal didn't exist.

When I ran pip --version, it reported pip 9.0.1.

After pip install pip --upgrade, it reported pip 20.1.1.

And with that, installation proceeds fine without any build (I made sure to clean out the old wheels first).

[Dimitrios Michail]

Yes I know, this is a private function available in 18 and afterwards. In 9, it does not even work.

The issue was indeed, that old pip versions do not know anything about manylinux2010 which means

they do not accept them. Thus, the requirement is to use `pip >= 19.0`. 

We tried to build with `manylinux1` but it is not possible, as `native-image` requires glibc 2.12 and manylinux1 

is way older.  (I am already starting to recollect the times when switching from gcc 2 to gcc 3 :-) )

Anyway, I will update the installation guide, to note that we require `pip >= 19.0`. 

--

You received this message because you are subscribed to the Google Groups "jgrapht-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jgrapht-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jgrapht-dev/4d3d0a07-9149-4b0c-adf9-0b768491c206%40googlegroups.com.

[John Sichi]

Awesome!

Joris, do you think you'll have time to push out a release on the Java side?

To unsubscribe from this group and stop receiving emails from it, send an email to jgrapht-dev+unsubscribe@googlegroups.com.

[Joris Kinable]

Yes, I should be able to work on that today or tomorrow.

I was hoping to find a solution for this: https://github.com/jgrapht/jgrapht/issues/884

It's quite annoying that the search function is broken. I'm not exactly certain whether this is a bug in one of the maven plugins, or whether we are somehow not completely complying with the modular design of Java 9 and beyond.

Joris

Awesome!

To unsubscribe from this group and stop receiving emails from it, send an email to jgrapht-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jgrapht-dev/4d3d0a07-9149-4b0c-adf9-0b768491c206%40googlegroups.com.

--

You received this message because you are subscribed to the Google Groups "jgrapht-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jgrapht-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jgrapht-dev/e8542a6d-0592-4d14-8ba2-0d4b4e9ca511%40googlegroups.com.

[John Sichi]

Last time I investigated that one, I'm pretty sure I verified that the hack from stackoverflow worked, so if we can figure out how to apply the necessary file munging as part of the javadoc build, we should be able to "fix" it.  But yeah, it would be nice to understand what's really going on.

Awesome!

To unsubscribe from this group and stop receiving emails from it, send an email to jgrapht-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jgrapht-dev/4d3d0a07-9149-4b0c-adf9-0b768491c206%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "jgrapht-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jgrapht-dev+unsubscribe@googlegroups.com.