Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 708440 - dev-util/bats-core : Bash Automated Testing System
Summary: dev-util/bats-core : Bash Automated Testing System
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Default Assignee for New Packages
URL: https://github.com/bats-core/bats-core
Whiteboard:
Keywords: PullRequest
Depends on:
Blocks:
 
Reported: 2020-02-06 01:24 UTC by Lucian Poston
Modified: 2021-01-14 06:31 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lucian Poston 2020-02-06 01:24:58 UTC
dev-util/bats-core: Bash Automated Testing System

https://github.com/bats-core/bats-core

The is a community fork of the unmaintained dev-util/bats currently in gentoo's ebuild repo. See https://github.com/sstephenson/bats/issues/150 for the history lesson.

Bats is a TAP-compliant testing framework for Bash. It provides a simple way to verify that the UNIX programs you write behave as expected.
Comment 1 Nelo-T. Wallus (ntnn) 2020-02-06 19:40:25 UTC
Please see my comment here regarding bats-core: 
https://github.com/gentoo/gentoo/pull/12280#issuecomment-503038704

My stance hasn't changed and looking at the merged PRs in the repo bats-core hasn't changed either:
https://github.com/bats-core/bats-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Amerged

Of course you're free to find a proxy to maintain bats-core.
Comment 2 Lucian Poston 2020-02-06 21:23:01 UTC
Thanks for that note, ntnn.

Just for some additional background, my motivation for adding bats-core is that the seemingly majority of BATS users are using bats-core (based on a cursory look around larger github projects and stackoverflow). For example, the available github actions that run BATS use bats-core, so I wanted a way to use the same version of bats when running tests locally as is used in the automated tests.

I figured others were in a similar situation, so hence this ebuild.
Comment 3 Nelo-T. Wallus (ntnn) 2020-02-06 21:47:23 UTC
Thanks for the background.

Currently there are 11k mentions of sstephenson/bats:
https://github.com/search?q=sstephenson%2Fbats&type=Code
And 2k of bats-core:
https://github.com/search?q=bats-core&type=Code

It does seem like bats-core will become more prevalent with time, especially since bats-core is packaged in various development package managers.

To note though - GitHub Actions are user created and the PR to merge the action is stale as well:
https://github.com/bats-core/bats-core/issues/251

Poly-C and I had toyed with a few possibilities to package bats and bats-core.
1. Separate exclusive packages (like from your PR)
2. Switched source based on flag (which will get messy the more bats-core differs from bats and the more used forks appear)
3. Separate packages, executable target of `bats` switchable with eselect

Personally I'd prefer the third option - this allows both projects to be used at once and to switch target of the `bats` link with eselect.
That would require an eselect module and package.

I'll prepare the changes in dev-utils/bats and an app-eselect/bats package this weekend.
If you're keen on maintaining bats-core you can make the appropriate changes in your PR, otherwise I could maintain it with Poly-C as my proxy.
Comment 4 Lucian Poston 2020-02-07 03:41:07 UTC
#3 is fine. The main reason I didn't go that route was vanilla bats seemed dead dead per https://github.com/sstephenson/bats/issues/150 , so an eselect module was overkill in my estimation.

That said, I can make the changes to work with an eselect module in bats-core ebuild and maintain it.
Comment 5 Joonas Niilola gentoo-dev 2020-03-03 05:52:17 UTC
How is the eselect package looking? https://github.com/gentoo/gentoo/pull/14576 needs to be updated with however you plan to proceed. 

I think the eselect method will be a bit too hacky for this, but I guess there are a lot of testing scripts with 

  #!/usr/bin/env bats

which kind of makes it necessary. I also think just using soft blockers on both packages towards each other works too. Have you thought what you need to do with eselect? You still can't have colliding binaries or man pages.
Comment 6 Lucian Poston 2020-04-03 00:18:52 UTC
It doesn't seem like ntnn has time to look into writing an eselect module, so I'll look into doing it over the weekend or perhaps next week.
Comment 7 Henning Schild 2020-07-17 19:18:06 UTC
I am not sure we should have both and go with an eselect, bats-core added new significant features and bats seems rather dead. And from what i can tell bats-core is backwards compatible and the current maintainer has a strong focus on that.

So here is another PR where i add myself as a proxy maintainer to solve that part ... https://github.com/gentoo/gentoo/pull/16409
Comment 8 Joonas Niilola gentoo-dev 2020-07-18 06:11:57 UTC
Okay, I'm thinking the best and easiest way to go forward is just to replace "bats" with "bats-core". Ie just switch the source URL in a version bump and call it "bats". 

How does this sound? Are they compatible?
Comment 9 Nelo-T. Wallus (ntnn) 2021-01-13 22:07:42 UTC
This bug can be closed as Henning Schild took over dev-util/bats and the newest version targets the bats-core project.
Comment 10 Joonas Niilola gentoo-dev 2021-01-14 06:31:11 UTC
Sure, thanks!