Future of bpkg

[jwerle]

As I look through the issues, the open pull requests, and the overall state of bpkg, I wonder: Where to from here?

This project was able to see some corporate sponsorship through committed hours, but those days are long gone, and it has become difficult to give the much deserved attention to bpkg over the years. I find myself with new energy and time to be able to commit again.

Issues I think that should initially be addressed:

• Test coverage - Test your code #72
• Use shellcheck - Code quality #78
• Migrate from package.json to bpkg.json (with backwards compatibility - we did something similar with clibs) - Add support for bpkg.json, next to package.json. #124
• Make installation easier
• Make publishing easier
• User guides
  • Best practices
  • Pitfalls

I'd love some thoughts or feedback from anyone interested in seeing this move forward ❤️

[Potherca]

Some thoughts:

• I suffer from a similar affliction where I would love to contribute but do not always have as much time to spend as I would like.

• Something I tried to put my effort in first is writing tests. The reason for this is that, in its current state, it is too easy to accidentally break things or create unwanted side-effects when making the code adhere to shellcheck rules.
  (I'd gladly attempt to free up more time to get that moving again)

• Fixing the code, making installation easier, making publishing easier, and user guides could be worked on in parallel.

• Regarding publishing (as I commented on publish #5)

  Creating a simple site where users can add their packages directly seems like a better solution.

  The source-code for packagist (PHP) and rubygems is available on github.
  Maybe a BPKG-specific fork could be created using one of those? (Or another language's package manager).

• This makes me think it might be a good idea to close some of the duplicate tickets to reduce the (cognitive and motivational) workload

• I think all of these things belong in a v1, no v2 needed (yet)

But yeah, I would love to give this project more love!

[vipyne]

I echo @Potherca and @jwerle it's at the top of your list- tests. I'm happy to help write some (because I really want to run shellcheck) but I'm unsure of the best format or framework. Once a framework is in place and a test or two is written, it could be a great low hanging fruit / first issue for other contributors to add more tests.

[Potherca]

Creating (more) tests won't be something I will be able to work on in the near future, as that is a high-energy effort for me.

But, prompted by @szepeviktor recent comments, I've taken a first step towards resolving our shellcheck violations, by indexing the problem in #78 (comment). I hope to add incremental MRs (to at least bring the number of violations down) in the coming weeks/months, as that is a low-energy effort for me.

I've also implemented a first-draft of supporting bpkg.json in #124

[Potherca]

Just opened #125 which makes a start fixing all Shellcheck violations.

[kirtfitzpatrick]

I came to bpkg looking for a library that would let a script that depends on a library to pin itself to a particular version. bpkg exceeded my wildest expectations for a bash package manager and I'm totally sold on it yet it's ability to pin a script to a particular library package version doesn't work that well for me.

In our use case we have many bash scripts for various purposes in a repo. And I understand that I can install a certain version locally but, unless I'm missing something, if I installed a package version for one script in a directory, all the scripts in that directory would also only be able to use that version. i.e. I can't have two scripts in the same directory that depend on different versions of the same package.

A method to pin a script to a particular library version would be really helpful and similar to what other package managers offer. Is there anything like that in the works? And what are people's thoughts on how that should be implemented?

Thanks!

[jwerle]

I love the idea! We'd happily review a PR

[kirtfitzpatrick]

Awesome. I may be able to get time assigned to this at work, or I may take a stab at it on a weekend. Do you have any thoughts on the architecture or could you point me towards any package managers out there that implement this in a way we may want to mimic?

Thanks!

[jwerle]

@kirtfitzpatrick at this point I am open to anything. bpkg is a very simple poor mans copy and paste tool that does not do anything fancy for package version resolution, deduping, hooks, etc. What are you thinking?

[jwerle]

I echo @Potherca and @jwerle it's at the top of your list- tests. I'm happy to help write some (because I really want to run shellcheck) but I'm unsure of the best format or framework. Once a framework is in place and a test or two is written, it could be a great low hanging fruit / first issue for other contributors to add more tests.

shellcheck getting integrated in the #140 PR

[kirtfitzpatrick]

@jwerle Ah sorry. Soon after posting here last year I switched to a different project in TypeScript. ¯_(ツ)_/¯ I still love the bpkg project and still use and maintain my 'chap' module regularly. Perhaps someday...

[jwerle]

@jwerle Ah sorry. Soon after posting here last year I switched to a different project in TypeScript. ¯_(ツ)_/¯ I still love the bpkg project and still use and maintain my 'chap' module regularly. Perhaps someday...

no worries! This is OSS and it takes it sweet time to get anything done 😅