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
Details
Details
tests have been updated
Diff Detail
Diff Detail
- Repository
- rDLDPY PyPI loader
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 1410 Build 1754: arc lint + arc unit
Event Timeline
| swh/loader/pypi/loader.py | ||
|---|---|---|
| 251 | 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! | |
Comment Actions
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).
Comment Actions
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.
| swh/loader/pypi/loader.py | ||
|---|---|---|
| 251 |
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 | |