Page MenuHomeSoftware Heritage

Rework branch names to align them with git origins
ClosedPublic

Authored by olasd on Sep 19 2018, 3:40 PM.

Details

Summary

This modification is two-fold:

  • For releases with a single sdist, generate a branch named refs/tags/<version>
  • For releases with multiple sdists, generate branches named refs/tags/<ver>/<filename>

Depends on D423

Test Plan

tests have been updated

Diff Detail

Repository
rDLDPY PyPI loader
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

zack added inline comments.
swh/loader/pypi/loader.py
250

so, what is the rationale for doing this?

I understand the desire of uniformity, but uniforming on what git does seem rather arbitrary and not necessarily future-proof. Git might change what it does in the future, and we will be stuck with a weird naming convention in the PyPI loader. Also, that is not what we do with, say, the Debian loader.

I think we should use something close to the PyPI terminology. And I'm personally totally fine with the fact that to make sense of branch names one should know the logic of the loader (which we should document…).

So, concrete proposal: 'release/%s/%s' % (release, filename)

And thanks for the test!

Ok.

I guess that concludes the discussion in D409 then (mercurial tags representation in swh model ~> snapshot with an equivalent naming convention).

Shall we add a case to check the multiple sdist case (later sounds good to me).

This revision is now accepted and ready to land.Sep 19 2018, 3:50 PM
In D424#8216, @ardumont wrote:

I guess that concludes the discussion in D409 then (mercurial tags representation in swh model ~> snapshot with an equivalent naming convention).

Nope, it does not. Here we have already decided that we will not have release objects (for consistency with other archive/package loaders), there the jury is still out.

This revision was automatically updated to reflect the committed changes.
In D424#8227, @zack wrote:
In D424#8216, @ardumont wrote:

I guess that concludes the discussion in D409 then (mercurial tags representation in swh model ~> snapshot with an equivalent naming convention).

Nope, it does not. Here we have already decided that we will not have release objects (for consistency with other archive/package loaders), there the jury is still out.

Ah, quite right! Thanks.

swh/loader/pypi/loader.py
250

... (which we should document…).

The readme does [1] (well, not entering into details though).

That will need improvments.

https://forge.softwareheritage.org/source/swh-loader-pypi/browse/master/README.md