search

ihabunek / toot

toot - Mastodon CLI & TUI
GNU General Public License v3.0
1.16k stars 111 forks source link

why the extra (duplicate?) source-balls for each github "release"? #133

Open bill-auger opened 5 years ago

bill-auger commented 5 years ago

github automatically exposes a source-bal for each git tag e.g. https://github.com/ihabunek/toot/archive/0.24.0.tar.gz

yet there is another beside it - is there a particular reason for this extra manual step? - off-hand, the significant difference i see is that the manually uploaded one does not contain a license nor changelog - that is the one that the AUR packager has chosen, and i am trying to discover why

ihabunek commented 4 years ago

Sorry for the late reply.

This was requested by some package maintainers. Apparently the tarballs generated by GithHub are not immutable, and can sometimes change in the future. They wanted something provided by the maintainer which is guaranteed to stay the same.

It's probably a good idea to add the license and changelog though.

bill-auger commented 4 years ago

hello ivan - thanks for responding - ive noticed recently that toot is broken on an arch system with python 3.8; so its good to know that you are attending the project - i may be posting some bug reports soon

just FWIW regarding this ticket, if that is the only reason for the manual step, it is not necessary; and one could easily argue the very opposite case, in terms of assurance - if it were me who was asked to do that, this is what i would have told that person ...

firstly, it does not guarantee that the file wont change, any more than the git tag guarantees that the git tag wont change; because just like a git tag, you can easily replace it at any time - that is even less of a guarantee really, because it can be replaced without modifying the git repo in any way - that means there is no simple way to verify that the manually uploaded source-ball is related to the VCS contents at all

secondly, if the git tag is never moved, then contents of the source-ball, and its checksum will not change - if the source-ball ever did change, that would be easily detectable; because the checksum would not match anymore - for an AUR package, that would cause the build/install to fail; which is exactly why they all include checksums

the git archive <TAG> command should produce an identical source-ball to what github makes, with the same checksum - so, a git tag really is sufficient, and more credible; because it is authentic to the VCS contents, and more easily verifiable to be so or not

ihabunek commented 4 years ago

Ah, it's debatable. I'm not very experienced in packaging and the needs of maintainers. This was requested and it's not a big problem for me, so I'm doing it on each release.

Regarding bug reports, they're always welcome. Even more if accompained with patches. :D

ihabunek commented 4 years ago

See, already I'm getting complaints about files not being in the right place. :D My problem is that I'd much rather pour my time into developing toot instead of juggling the mess that is python packaging.

bill-auger commented 4 years ago

i was mistaken about any problems with python 3.8 - the problems were all because the 'toot' i was using was built against python 3.7 - release 0.24.0 works perfectly with python 3.8 - i only had to re-build it

you can probably just add to setup::classifiers in setup.py:

'Programming Language :: Python :: 3.8',
bill-auger commented 4 years ago

i did not realize you released a new version - release 0.25.0 is good too

bill-auger commented 4 years ago

i read the python setuptools documents to learn a bit more about this - from what i learned, the python way to create a source-ball is with the setup.py sdist command - the files that will be put into the source-ball are not related to anything in the setup.py script - that is determined only by the MANIFEST.in file; which in this case, specifies every file in the source tree (the recursive '*') - the 'data_files' key in setup.py is for specifying files that will be installed with setup.py install

i ran setup.py sdist after removing the 'data_files' entry (just as it was not there in 0.24.0) and all files in the source tree were in the generated source-ball, just as the setuptools docs promised; so im not sure why there was ever any discrepancy - the 0.24.0 source-ball must have been generated some other way than either setuptools or git

setup.py sdist is only particularly useful if you want to specify exactly which files go into the source-ball and which do not - in some cases, the maintainer may want to remove some files from the source-ball, that are in the development tree, such as the CI mete-data; but it is rarely strictly necessary - that is just a matter of tidiness

if every file in the source tree goes into the source-ball, then git archive <TAG> would do the same thing - it produces a source-ball identical to the one that github auto-generates for each git tag; which is why i mentioned that if every file in the source tree is to be into the source-ball, then it is totally redundant to create and upload a source-ball manually - if you must make a duplicate, run either git archive <TAG>, or setup.py sdist - im pretty sure they will produce the same thing, and both will include all files in the source tree; and should be identical to the auto-generated one