Skylib will no longer regularly accept feature requests

[susinmotion]

Skylib was originally developed to support Google projects, and over time it’s become increasingly difficult to reconcile Google and non-Google requirements. We’re aware that contributing to Skylib is often a frustrating experience. We’re not always responsive to pull requests, and even when we are, the review process can be slow. On the Google side, merging pull requests to Skylib is also time consuming and frustrating. Differences between Google’s version of Skylib and the OSS version of Skylib mean that we often need to rewrite pull requests to avoid internal breakages, and update the scripts that keep the versions in sync.

In order to mitigate this, we are putting Bazel Skylib in Google-first mode. As of July 2024, Skylib will continue to be supported and to evolve to meet the needs of Google open source and internal projects, but it will now only accept pull requests that are applicable to Google projects. As part of the effort to reduce maintenance costs, we also plan to move some functionality out of Skylib and into Bazel and related rules.

Hopefully, this will add clarity to the situation that already exists, freeing up contributors to develop forks where needed, while knowing they can rely on the existing Skylib functionality. While we believe that Skylib will continue to provide useful functionality for most current users, there are alternative Bazel libraries (e.g., bazel-lib) that you may also wish to consider.

[brentleyjones]

Is bzl_library going to be moved into Bazel? That is currently a big reason that people continue to depend Skylib.

[susinmotion]

Yes, that's the plan!

[keith]

Did you / Google consider the other option of moving this repo to be community maintained? It seems like a strange message to the community to state that the most used bazel dependency is immutable from now on. It seems like one logical path moving forward would be to create a shared fork of this repo, and move as many public repos to use it instead, which I think would defeat the purpose of google making it read-only as well. Maybe it should just exist as a google-internal fork like some other repos do?

[susinmotion]

Yes, it was something we seriously considered, and it is an appealing solution. One reason we didn't go that route was the worry that we'd still have issues importing Skylib into Google's codebase for third-party projects like Tensorflow. The current state of affairs is that we mostly don't accept PRs, and there are already forks abounding from people who needed to get a move on with their work while we were slow at reviewing, so we consider the decision to make Skylib Google-first to be smallest change from the current status that still addresses the mismatch between what we advertise (please contribute!) and what we do (take a long time to review PRs). Hope that's at least a little helpful.

[susinmotion]

Another goal we had was making Skylib less of a hodgepodge of functionality. I could imagine pulling code out of Skylib and once Skylib is smaller and more cohesive, revisiting this question.