now at https://docs.softwareheritage.org/devel/swh-graph/

In D1910#44117, @olasd wrote:

It's clear that the current instructions won't work when running all commands in succession (because virtualenvwrapper's config won't have been sourced unless the session has been restarted), so I guess this change is better than nothing.

In D1911#44122, @vlorentz wrote:

What is this for?

In D1908#44071, @haltode wrote:

The "automatic" way is javadoc macro that updates the doc version each time it is modified, but I can also remove version and since attributes.

In T1964#36396, @sunweaver wrote:

@zack: Thanks for providing the tarball. However, I in fact need a tarred up Git repo until the moment that GPL was revoked, as I want to re-pulish it via GitLab (or Github). Do you think it is possible to get a copy of that git repo any time soon?

We certainly don't want to modify all Java files at each release.
So please either fix it the right way (which would probably mean some git subst var hackery) or at least for now just get rid of the version numbers from all Java source code - it's useless information anyway, as it belongs to the underlying VCS.

@sunweaver: did you see my answer above?

I can totally reproduce this issue.

Given the recent announcement by bitbucket about dropping mercurial support, the priority of this task has just increased.

[ I'm jumping in here, but obviously I'm missing the IRL context. ]

The "Build is green" review.

As discussed, please amend the commit before pushing to elaborate on why this is needed.

I disagree with this one. The right fix is making the doc build, not removing the dependency.

I'm approving this as it's good enough. But please make the seed a real random seed rather than hard coded (in a subsequent commit). It's *useful* to have a fixed seed for reproducibility, but it should not be the default and it should be possible to pass it externally, e.g., as a class parameter and/or CLI option.

• we should wrap the JSON return type more properly. Please use "result" instead of "content", everything else (like "timings" now, possibly other stuff in the future) will be metadata about the result

True, I will also rename "timings" into "metadata" because I don't like having both "Timing" and "Timings" class name.

I hadn't in mind to lift the timings up to the REST layer, but why not, it will enable doing interesting stuff using non Java clients. However, a couple of change requests:

In T1234#36008, @ardumont wrote:

In the end the PGPASSFILE stuff cannot work with one file globally defined.
Because for some reason, the authors decided that it needs to be only user readable...

Just wanted to mention here that @douardda and @olasd discussed getting a short URL style domain (I think it was swh.li, but I'm not entirety sure) for various shortening needs).

This is great! Thanks a lot.

Can you also add a clean-javadoc target, equivalent of clean-images ?

• make the echo invocations a function, e.g., info()
• use a common, but distinguishable prefix instead of just "#" which will allow to search for progress info in the potentially huge log-files, e.g., "* swh-graph:"
• maybe add a step number v. total number of steps (e.g., 2/5)

Sure, let's do that, but I've never touched anything related to SWH on PyPI, so I've no idea how to make it happen.
Whoever has an idea of how do to that, please just go ahead. (And feel free to tag any recent version for PyPI publishing; the currently tagged version was completely arbitrary, just because a tag was needed for $something.)

No objection from me on adding a more abstract node type. It would be a nicer API and, given it's gonna be on the python side only, it won't have any impact on perf.

In D1768#41627, @haltode wrote:

The mapping has always been a separate command but we can indeed add it to the generate_graph.sh script.

landed in a043b0ee04aae50f8c26f6a06aac1e6c9247340a

In D1768#41565, @haltode wrote:

Note that you also need to update the java/server/src/test/dataset/generate_graph.sh script since the Docker environment has changed.

• tests: update generate_graph.sh to match new docker layout

We want to test that the client part of a complete client<->server interaction works properly. The best way to do that is, in fact, to rerun the same tests we run on the server side, but via the Python client. If there is an easy way to just reuse the same test code (e.g., by generating Python tests from the Java ones, or vice-versa), go for it. But probably it isn't worth it, as there isn't much test code anyway. If there is no way to keep parity, we should go for something minimal on the Python side, e.g., just test one call per API endpoint, and keep a more complete coverage on the Java side (again: or vice-versa, if we prefer to maintain the Python test code base than the Java one).

Tnx, will do.

No, you're right, I didn't think of the global namespace of unified documentation.