Simplify packaging and publishing process
Instead of handrolled install.sh I switched the project to Makefile for installation. There's no benefit besides it being ~more familiar and 2x shorter.
More importantly though, I added pyproject.toml which is now main source of metadata (e.g. version & name), and Makefile pulls this information and seds it into install/package files which removes like 5 tedious steps from releasing a new version.
Now you can do changes, change version in pyproject and run make publish.
This breaks interface packages rely on because they need to invoke make install instead of ./install.sh --install, but I don't think that's a very hard thing to update. You will need to notify them though (namely AUR which has git variant, others will notice).
Actual diff is +148 -305, rest is just autogenerated .gitignore.
Hello o/
I will not merge this PR as is, because there are few things I want to change so I will:
- Cherry-pick the
pyproject.toml - Use your Makefile but with few changes (I prefer having hard coded version number in the git repo)
- I will update the install doc to use the Makefile
- I will get the
install.shscript back for compatibility (but it will just call the Makefile behind the scene)
This is one of my oldest project and its code is not very clean nor very standard... So thank you very much for helping improving this!
You're welcome.
Really not sure why I did this PR hahaha. I just saw a huge number of places where version number needs to be updated and a large custom install.sh and then things got out of hand.
I simply wanted to vendor it to remove the graphic and cropping applied to .cover.png files.
This project is mostly complete and still works well, I opened #23 for the only bug I encountered running it and it's a 1/2 LoC change so take a look while you're making the commit.
Hum, It seems to be too much work for me to review the Makefile for now so I will keep the shell script. I will only take the fix of your other PR and cherrypick the pyproject.toml for this release :)
It seems to be too much work for me to review the Makefile
It's pretty much the install.sh, only as a Makefile.
It's pretty much the install.sh, only as a Makefile.
Yeah I know but there are some changes and I really need to understand them all as I have to maintain this project in the future.
For example, what @$(PKG_CONFIG) --exists $(GTK_VERSION) is really testing? The presence of the GTK's .so? The .h? Does it also check the presence of the XML files used by GObject Introspection (/usr/share/gir-1.0/Gtk-3.0.gir)?
And also I want to maintain compatibility so I have to bring back the install.sh and make it call the Makefile... And to update the doc.
This project is in (really low) maintenance mode and I am currently very busy on other projects (Daily Mix playlists generator, Rivalcfg tool to configure SteelSeries gaming mice, YOGA Image Optimizer, etc.) and on doing research and writing articles for my blog (on DICOM (medicine imagery), on ImHex, and so on).
That's why I preferred releasing the fix and the project.toml as quickly as possible and letting this PR open for the day I have time to take care of it :)
Ok, no worries.
Those new projects sound fun and interesting, no pressure here, this PR doesn't change anything important so feel free to pick it apart and do what you like.
Coincidentally, my bachelors thesis is on volumetric rendering and I mention DICOM a lot, so I'll keep an eye out for that article :smile:, if you've found any samples of 3D CT/MRI scans please send them this way I have trouble finding any and would like to include them.
@$(PKG_CONFIG) --exists $(GTK_VERSION)
-
pkg-configis a "cross platform" (i.e. gnu) tool that querries package information from whatever package manager the distro provides- assuming it's present in build enviroments that also have GTK
- "--exists - check whether or not a module exists"
- that is, whether a specified GTK version (3.0) is installed.
- this replaces the check from
install.shthat ran a python script that tried using the package to detect error in including it - to test whether GTK 3 is installed.- they do the same effectively. Import will work in python if GTK is installed. If import works, GTK is installed and at least v 3.0.
Coincidentally, my bachelors thesis is on volumetric rendering and I mention DICOM a lot, so I'll keep an eye out for that article 😄, if you've found any samples of 3D CT/MRI scans please send them this way I have trouble finding any and would like to include them.
I have some CT and MRI and that helped me a lot for working on DICOM but sadly I cannot share them... I also had hard time to find examples I can share for my articles (in addition of hand crafted files just for the demo) but I found this:
- https://www.aliza-dicom-viewer.com/download/datasets [NOTE: some of the files only contains the DataSet without the headers so they must be completed to be opened :/]
- https://medimodel.com/sample-dicom-files/