Installation involves no less than 6 instructlab-* packages

[jpodivin]

Installing instruct lab is split across several packages, all of which need to be installed in order to obtain functioning environment. This is besides other, 3rd party dependencies, and indirect dependencies of packages concerned.

This creates two issues.

First and foremost, maintaining releases of six packages is inherently more complicated than maintaining 2. We could combine them all for distribution, but this would be prone to issues, not mention confusing to users of instruct lab as the pip packages wouldn't correspond to packages rpm packages.

Second, changes to code in dependent instructlab-* packages will require dependency declarations as part of the PR, covering the path in dependency graph. This approach has to be also implemented in CI, making sure that changes across the chain is tested in turn.

At the same time the APIs must be maintained rigorously, so that no incompatibilities between libraries arise.

Imho, it would be easier to combine at least some of the packages into general utilities/lib package.

[jjasghar]

This seems like something that should be in https://github.com/instructlab/instructlab not taxonomy.

[bjhargrave]

pip install instructlab works fine. I think you need to state your issue more specifically as related to packaging for distribution in linux as rpms, debs, etc.

[booxter]

@jpodivin not necessarily to disagree, but to add context.

1. the split reflects the team structure (there are separate squads for each of the libraries / components).
2. I believe one reason the project split out the code that originally lived under the umbrella of instructlab (CLI) repo was so that the same libraries could be used to build other services (e.g. REST API) without pulling CLI specific dependencies like click. Whether the project had to split into so many small pieces, and whether dependency issues could be solved otherwise (e.g. with optional dependencies), I don't know.
3. Folks envisioned separate communities for these pieces. This reason was documented at least in some new repo proposals.

I suspect there may be other, (better?) reasons for the split, but I don't know for sure.

[github-actions]

This issue has been automatically marked as stale because it has not had activity within 90 days. It will be automatically closed if no further activity occurs within 30 days.

[github-actions]

This issue has been automatically closed due to inactivity. Please feel free to reopen if you feel it is still relevant!