[Feature] Create bundled and non-bundled (downloadable dependencies/packages) versions

[BobbyESP]

Pull Request: Move to Downloadable Plugins

Description

This pull request addresses the following changes:

• Transition from Pre-packaged Libraries: We are moving away from using pre-packaged libraries in favor of downloadable plugins. This change aims to enhance flexibility, maintainability, and customization options for our project.

Changes Made

• All of Moved to Kotlinx-serialization and updated Gradle and Kotlin #254
• Moved to Gradle 8.1.4
• Moved to Kotlin 1.9.20
• Created a Jetpack Compose app (that can be removed later) for testing. I feel more comfortable with Compose than XML.
• Migrated to Kotlin DSL (Gradle config)

Benefits

• Flexibility: Downloadable plugins allow users to choose and update specific components independently (even if Python and FFmpeg are mandatory).
• Reduced Package Size: This transition helps in minimizing the overall package size (and also apps size that depend on the lib), resulting in faster downloads and reduced resource consumption.
• Easier Updates: Users can easily update individual plugins without waiting for a complete library update.

Testing

• Made just manual tests.

Additional Notes

• None by now

Related Issues

• Python & FFmpeg as downloadable plugins #248

Please review and provide feedback on the proposed changes.

[BobbyESP]

Not yt-dlp but updates of it in commit a71509

[BobbyESP]

The plugins support is almost finished; I have to change some things related to the initPython function and even the FFMpeg and Aria2c modules of the lib, but the YoutbeDL module itself can start to be reviewed.

[BobbyESP]

Created a build so you can try how is this going. Far from a final release!!!

You can see an example here

[BobbyESP]

The initPython function will have to be modified (as well as the other such as the FFmpeg and Aria2c) since the unzip process is already included in the download process. We should probably have to create different functions depending on the flavor

[BobbyESP]

@JunkFood02 Can we talk about how we should handle the libraries downloading? I mean. Should the download function be inside the init one or something like the already implemented in the app demo?

[BobbyESP]

EDIT: FIXED

Seems to be an error at build time because of the app, here is the log.

I think that the targetConfiguration isn't correct since I would say that the target should be "bundled" or "nonbundled" but when using those cases Gradle isn't able to find the library:

implementation project(":library") targetConfiguration("bundledDebugRuntimeElements")

[JunkFood02]

This PR is quite large (4000+ LoC) and hard to review. Could we please split it to smaller and more focused PRs, each addressing a specific topic?

[BobbyESP]

The changes that are necessary for this functionality require all the work put into this PR since it means almost a rewrite of the library. I will still try to adjust the code to reduce the number of lines and changes, but please keep in mind that this proposed separation requires the changes made.

[BobbyESP]

I will start by removing the Jetpack Compose app

[JunkFood02]

The changes that are necessary for this functionality require all the work put into this PR

We can just make a pull request depending on another, which means a pull request could only be merge after all it's dependencies got merged into the target branch. This allows us to gradually applying the changes and review them in smaller chunks, making the process more manageable.

[BobbyESP]

The changes that are necessary for this functionality require all the work put into this PR

We can just make a pull request depending on another, which means a pull request could only be merge after all it's dependencies got merged into the target branch. This allows us to gradually applying the changes and review them in smaller chunks, making the process more manageable.

That's interesting and cool. Can we create those chunks in some way or I have to create different branches with manual changes?

[JunkFood02]

I have to create different branches with manual changes

I'm afraid you'll have to do so by hand since github doesn't support such cool pull requests while gitlab is offering this as a paid feature

You can start with building upon an existing branch. Submit a pull request when you're ready for a new, separate feature and create a new branch based of the current branch for further changes. Just make sure each branch(PR) focus on a single modification or topic for clarity.

Also, when developing on parallel branches simultaneously, avoid modifying the same files. You know what would happen 😈

[JunkFood02]

For example: you can start with the update_library branch

1. migrating to Gradle Kotlin Script
2. update dependencies
3. other independent changes that could be working on at the same time
   • a new compose app for testing
   • replace fastxml with kotlinx.serialization
   • ...
4. decouple executables and dynamic-linked libraries (this PR)

[BobbyESP]

Hahah okay, thanks for the help! I will do this as it should be done, as you told me. I'll keep this PR open for a while, but when I think the other smaller PRs cover everything done in this one, I'll close it.