Split in libtopgrade and topgrade

[s34m]

Split of the backend from the frontend to allow for further improvements on both and to maybe allow the addition of additional features like topinstall(install packages), topsearch(search packages) to make it an universal cli package manager frontend like for example Packagekit + Gnome Software is for GUIs.

I wanna know what your opinions are about that.

[tranzystorekk]

TBH I prefer topgrade doing just the upgrade job, full-blown pkg-manager frontends rarely live-up to their potential.

[s34m]

TBH I prefer topgrade doing just the upgrade job, full-blown pkg-manager frontends rarely live-up to their potential.

True
Except that, I think splitting the frontend and backend up would still be a good idea.

[ssmendon]

I agree that splitting the front and back end is a good idea. Modularization has the following benefits:

• Opportunity for a larger refactor of the library components with clear documentation, extensibility, and testing
• Ability for other users to take pieces of this library for use in their own projects more easily

I'd be happy to work on this. Since this is a large change, I'll spend some time developing a small proposal to see what the alignment is like.

@DottoDev, what was the reason for commenting out lib.rs? Want to know if there's any considerations I should know about.

Opens

Here are some concerns I had which I would appreciate some discussion of to get a better idea of the community consensus.

1. License
   The current license used is GPL-3.0. Most Rust packages use a more permissive license (typically dual-licensed under Apache-2.0 or MIT). I want to have a discussion about the license used and how to follow the GPL-3.0's recommendations (e.g. header on each source code file, who owns the copyright per contribution, etc). To clarify, I'm not asking us to change the license (that would be difficult). I just want to have some alignment on implementing its best practices.
2. Module refactoring
   config.rs is ~1000 lines of code without any tests. We should separate the responsibilities in a more granular fashion and add unit tests, doc tests to each section of the code as part of this separation.

[s34m]

About lib.rs and tests.
lib.rs is there so tests could be written in the tests/ folder and can access topgrades functions.
And I'm currently working on writing unit tests for the package managers but this seems to require much more work then I initially thought.

[ssmendon]

Right, makes sense. Maybe as a first step toward a separation of front- and back-end, I could work on un-commenting the pub mod declarations in lib.rs and resolving any import errors?

[s34m]

Because i also used it as a reference implementation for my tests you could try and write a wrapper, maybe in a separate file, for all functions required by the linux upgrade_alpine function and let this function use the wrappers so that it "technically" uses the interface and not the implementation. This would be the first step for a separation and should be very simple.