-
|
I have a project with releases cut automatically by a cron every so often on a regular schedule. Since the release schedule is basically a calendar, I would like to switch the versioning to a calendar-style scheme. However this project is a bit peculiar: it's pretty much only a compilation from an upstream data set which has an irregular and unpredictable change schedule. The project generates linear versions deterministically from a fixed point of the upstream so currently if the upstream has had no change since the previous release the same version number and package will be generated, and pypi will essentially ignore the upload. With a calendar-based version scheme, every release will be different, and so naively the project would keep creating useless releases on pypi. Obviously this can be mitigated by keeping the information of the released upstream commits somewhere in the project's repository, but maybe there's a way to negotiate that with pypi e.g. some sort of etag that could be sent to pypi alongside the release causing pypi to ignore the files even if the version is novel? I didn't find anything when searching but I figure maybe someone'll have an idea? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
You could probably compute the hash of your data blob and save that+timestamp in a text file in sdist (you could think of it as a cache key too). Then, you'd have to have a job/step before building your new dists that could download that sdist, untar it and make checks to decide whether to proceed. I guess you could also add this data and even importable/invocable helpers into wheels and just install it, then retrieve the data by calling something. But this might be an overkill if you don't have a use case for exposing that to the end-users. |
Beta Was this translation helpful? Give feedback.
You could probably compute the hash of your data blob and save that+timestamp in a text file in sdist (you could think of it as a cache key too). Then, you'd have to have a job/step before building your new dists that could download that sdist, untar it and make checks to decide whether to proceed.
I guess you could also add this data and even importable/invocable helpers into wheels and just install it, then retrieve the data by calling something. But this might be an overkill if you don't have a use case for exposing that to the end-users.