Distribute as Composer package

[AlexSkrypnyk]

Is your feature request related to a problem? Please describe.
Bats-core can currently be downloaded using a NodeJS package manager. It would be great if we can let it be downloaded by the Composer PHP package manager.

Describe the solution you'd like
Add composer.json, similar to package.json, and submit it to Packagist.org

Describe alternatives you've considered
N/A

Additional context
In PHP projects that may have some scripts, the only way to get Bats installed for testing is through NodeJS package manager, but it may not be available in the PHP environment.

[martin-schulze-vireso]

Would it be possible to have that in an extra repo as not to clutter the main repo any further?

[AlexSkrypnyk]

@martin-schulze-vireso
We are talking about adding a single composer.json file. I'm happy to provide a PR if you are keen to add this.

Please note that other libraries, such as Bootstrap (which is not a PHP library), provide composer.json just for the sake of being used in PHP ecosystem
https://github.com/twbs/bootstrap/blob/main/composer.json

[jasonkarns]

I'm not against adding this if it helps. Though I would like to add a few additional notes of clarification.

Firstly, when I originally added the package.json manifest to my own bats plugins, it was not as a means of distribution. Bats was (and is) installable by simple git-cloning. Or curl-ing the release tarballs. In fact, I believe it was years before I started publishing those plugins to the npm registry. The initial addition of package.json was solely to simplify our own CI setup and local testing workflows. I don't recall when package.json was added to bats-core itself, but I wouldn't be surprised if its initial addition was for similar reasons.

the only way to get Bats installed for testing is through NodeJS package manager

Reiterating, node and npm are absolutely not required to install or use bats. git-clone or curl the release tarballs as is common with shell utilities. Or install with homebrew on mac or linux. Or dockerhub. These and other installation mechanisms are documented.

But really I want to push back a little (gently) on this:

We are talking about adding a single composer.json file

It's not only a single file. For it to be installable by composer, we would also need to publish it to some registry, no? Which means (probably trivial, but non-zero) effort for setting up and configuring CI to publish to an additional endpoint. Which also brings with it security implications for having publish tokens/credentials managed securely.

But sure, some package managers don't require the package to be published; they can install directly from a git repo. So there's even more: adding composer.json into the core repo means additional, perpetual, maintenance and support of a package manager and ecosystem that the core maintainers (may? likely?) have no experience with. I know I don't. And having it in the core repo is a declaration of official support; indefinitely. That's certainly not "just a single file".

And then follow the requests for a cargo.toml, a .gemspec, a maven manifest et. al. To be clear, we do have to draw the line somewhere. This is a Bash testing tool. It is installable with the common utilities in a shell environment.

But I also agree that, among the many and varied language platforms that are in widespread use, the ecosystems that likely have a lot of shell scripts in need of testing is likely php, node and ruby. So I would personally not be against adding composer.json. But then again, I haven't been an active maintainer for some time, so I would defer to those whose time is actually invested in the subsequent support.

[AlexSkrypnyk]

Packagist.org is a registry for Composer. It auto-syncs with GitHub repo. Setup is as simple as providing a URL of GitHub. No further maintenance required.

Installing from GitHub via Curl is not simple - it is not possible to lock to a version easily. Package managers handle that.

I use bats in 20+ projects and using a package manager is a huge benefit. It’s just that it is currently only NPM and non-js projects have to have it installed.

If bash to have own package manager - this issue would not exist in principle. But because it doesn’t exist - we have to use package managers from different languages to fill the void.

[jasonkarns]

It auto-syncs with GitHub repo. Setup is as simple as providing a URL of GitHub. No further maintenance required.

Nice! Does packagist somehow derive the version from the git tag? (I assume composer requires a version number in its manifest which will need to be accounted for in the release automation.)

Installing from GitHub via Curl is not simple - it is not possible to lock to a version easily.

curl -sSJLO https://github.com/bats-core/bats-core/archive/refs/tags/v1.10.0.tar.gz is pinned to v1.10.0. (The tarball urls for each release/tag are published on Releases page, but the url construction is a fixed format anyway.)

Fancy construction is straightforward with the gh cli and gh api, if something other than pinned downloads is required. (Though, since bats isn't a library and doesn't have any transitive deps, it doesn't have the same dependency-resolution needs as a typical lib dep; so that is likely unnecessary for most use cases.)

I think if there is a next step here, it is to open a PR with the necessary composer.json file and automation changes necessary that will bump the version in composer.json on release.

[AlexSkrypnyk]

Does packagist somehow derive the version from the git tag?

Yes. Everything automated.
You do need to have an account in Packagist.org to submit the package.

---

Re CURL. I'm not arguing that it is not possible or hard. I'm saying that if Composer already used as a package distribution method for other packages, it would be easier to add BATS through composer. Hence this issues.

---

Automation changes necessary that will bump the version in composer.json

This is not required. From https://packagist.org/about:

Managing package versions
New versions of your package are automatically fetched from tags you create in your VCS repository.

The easiest way to manage versioning is to just omit the version field from the composer.json file. The version numbers will then be parsed from the tag and branch names.

Tag/version names should match 'X.Y.Z', or 'vX.Y.Z', with an optional suffix for RC, beta, alpha or patch versions. Here are a few examples of valid tag names:

---

I'm happy to provide composer.json in PR.

Thank you