Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request - better package management interfaze #2427

Open
podraco opened this issue Feb 21, 2021 · 3 comments
Open

Feature request - better package management interfaze #2427

podraco opened this issue Feb 21, 2021 · 3 comments

Comments

@podraco
Copy link

podraco commented Feb 21, 2021

Allow to arbitrary update for included libs
this is a simple idea, allow the developer to request an environment update for a specific library, something like:
p4a upgrade # to cast an update for every lib
p4a upgrade lib1# to cast an update for lib1

This would save time for people who's working with a specialized or private dependencies that need to be updated to fix an issue on the final app that it's not caused by the app's implementation, instead of having to download everything again.

@obfusk
Copy link
Contributor

obfusk commented Feb 21, 2021

Could you be a bit more specific about how you want this to work? Maybe give an example?

@podraco
Copy link
Author

podraco commented Feb 21, 2021

Let's see...
If you're working in a team in charge of the main app and a second team works with a specific lib that your app needs to use to work on the android app,
in this scenario, here's a bug on your app, but after hours of looking through the code you identify that the bug is not part of your team code, but from the dependency from the second team, if you want to update the lib, you would need to clean the whole cached libs,
the idea is that you onlye have to update the second team lib.

@mzakharocsc
Copy link

I second this.

As it stands triggering a submodule rebuild re-runs many triggers of already built packages, and re-runs many global steps (such as .pyc generation, moving files around, etc) that potentially could be all cached per-module, and only the final archive should be re-generated.

As an example on where this 'just works', take a look at bitbake . bitbake also has to support cross-compiling python, and building python packages/dependencies, not any different from what p4a does, but its core emphasis is on dependency generation,caching and build-time optimization.

bitbake is maybe too mature/complex for p4a purposes, but its ideas can be used as an 'inspiration' for p4a. Things such as advanced dependency generation (if you rebuild module a, which is a downstream dependency of module b, then rebuild module b also), runtime vs build time dependencies, etc.
https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#dependencies

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants