Kint version

[picasso]

I suggest adding in Kint the ability to know the current version. Now Kint itself does not store the version number anywhere and you can find it only by looking at the releases. But the release version (now 3.3) and the master branch version are the same thing? But the Readme suggests downloading phar from the link: Download the file

And what version does this phar get?

In fact, a method or property that stores the current version would be very useful. I understand that this introduces problems to maintain it in an actual state, but ways have long been invented for this.

[jnvsor]

I'd love to get this done if anyone knows a reliable way

I understand that this introduces problems to maintain it in an actual state, but ways have long been invented for this.

Can anyone enlighten me as to what these are? I don't want to just store the latest release, that's kind of pointless since the phar download link on the site points to master.

If we commit the commit hash the hash will change so obviously we can't commit the version in the code itself. If the build process was separate from the code that'd be easy enough, but it's not. The phar is committed and the repo's code is loaded directly by composer.

This chicken and egg problem can be partially solved by using the ident in .gitattributes but it wouldn't work for the phar file since phar format has all sorts of fancy compression options and so on (And it'd probably just break an offset)

[picasso]

Of course, any project has its own specificity. First, I suggest add version to package.json - this is already the norm. Further, my offer was to find out the version could be programmatically, calling some function. It is quite a real situation for projects of integrating KINT in their environment - it is important to know the version (it is equivalent to knowing what is supported and what is not).

Of course, the maintenance of such a function will add problems (I periodically forgetting to update the version of the project). As a possible solution - include package.json in the build and read the version from there. Then it will be updated only in one place.

[jnvsor]

First, I suggest add version to package.json - this is already the norm.

That may be the norm for npm packages but kint is a composer package, and no-one does/you're not supposed to add the version in composer.json (Precisely because it tends not to get updated properly)

To quote the composer docs:

The version of the package. In most cases this is not required and should be omitted (see below).
[...]
Optional if the package repository can infer the version from somewhere, such as the VCS tag name in the VCS repository. In that case it is also recommended to omit it.

Note: Packagist uses VCS repositories, so the statement above is very much true for Packagist as well. Specifying the version yourself will most likely end up creating problems at some point due to human error.

If it's going to result in "Periodically forgetting to update the version of the project" I'd rather omit it entirely. I'd rather have users not sure what version they're on, than sure of something that isn't so.

Since composer handles versions itself, I could take the tree hash of the src dir and put it in the phar file. It wouldn't help the user finding the version but it would be useful for debugging. Still, that's not super useful for you, since you could just as easily send me a hash of the phar for the same effect.

[picasso]

Well, I understand your position. Unfortunately, for the composer, I do not know a simple and reliable solution for storing version. And what decision to choose is just you decide, I can only ask.

[jnvsor]

Well in composer if you know where your vendor folder is you can walk the installed.json to find it (You can check out Utils::composerGetExtras to see roughly how that's done)

So it's really the phar that's the issue (Since you have to commit the version inside it)

[picasso]

So it's really the phar that's the issue (Since you have to commit the version inside it)

Who creates the phar? Why not combine it in one script - first update the values of variables in the source codes, and then call what the phar generates ...

In my projects, I solve this with mini-automation - I write a script that launches the Build for the project and at the same time changes values of variables or string constants in all the necessary files. Once to spend time and write this script, and then do not think about it. Nodejs has many convenient modules for replacing values in files (for example, with regex). I haven't found another solution yet...

[jnvsor]

Maybe github actions could be misused to produce the phar as an artifact instead of committing it to the repo... I'd have to look into that though, since I've never worked with it (The build process predates github actions)

[jnvsor]

I've looked closer into GHA artifacts, and it looks like they only stick around for 90 days. If you had a release for every commit I'm sure you could have GHA automatically attach the built phar to the release but we don't have releases that often so I'm thinking just committing the phar is the simplest option right now. Unfortunately that precludes storing the current commit in the phar.

Since I won't rely on GHA to store the build artifact there doesn't seem to be a way to do this other than manually keeping track. I could do that for major versions (There's already a "Version number" in the PHP version check) but keeping that updated for minor or patch versions would be a nightmare.

I suppose we could add a "Version check" on CI runs but since the state of the repository (ie. the latest tag) isn't a component of the commit it would (For instance) give different results on the main repo than on my fork meaning I couldn't rely on my test commits to ensure everything works before putting a release live...

Long story short: On composer you can parse your package manifest to get the version, but the phar doesn't have one, and it can't be added to the phar automatically since the tag happens after the commit. I still don't have a sufficient solution, and I've given up unless someone comes up with something completely different.