Use OSGi (java) resolver to created managed (and secured) python application environments #153
Replies: 1 comment 1 reply
-
|
I see the point of having a package/feature declared in a way that a resolver would understand (especially as we use bundle resolution a lot for setting up our integration tests in Eclipse sensiNact, using That being said, I'm not sure how that would integrate with iPOPO: would it be a way to describe a list of bundles iPOPO would install? |
Beta Was this translation helpful? Give feedback.
-
|
>
> That being said, I'm not sure how that would integrate with iPOPO: would it be a way to describe a list of bundles iPOPO would install?
Certainly could be used that way. In the new bndtools project template...using the Python.Java distribution provider described here I start the IPOPO bundles in the example, and the osgiservicebridge gets the python code at iPOPO bundle start time from the java process. I was originally thinking of using OSGi meta-data, along with the OSGi resolver/wiring to build a python package resolver service....e.g. resolving the meta-data defined capabilities and requirements, with all their versions and ranges. I've learned that there is at least one python dependency manager called poetry, and I'm looking at it...it looks like they've implemented the resolver already, but I would guess it's not nearly as debugged as the OSGi resolver (framework-dependent impl of course). And...bndtools already has a resolver service that it uses to resolve the requirements/capabilities before first execution. BTW, with Java OSGi and the ability to add types of capabilities and requirements, I think it could make sense to define python (module) capabilities for expressing constraints rather than trying to reuse Java's dependency constraints (e.g. Import-Package, etc). Another use case might be a service for building python lock files that actually verifies/resolves/test all dependencies as per pep-0751. I can imagine generating python package meta-data bundles...with multiple versions...automatically/automated, and then resolving/wiring them in different combinations.
Yes.
Yes. Not having a classloader does have lots of implications. Maybe there is something there for Python to take advantage of. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Recently I read with interest this article about python managed environment metadata :
https://devclass.com/2025/04/04/python-now-has-a-standard-package-lock-file-format-though-winning-full-adoption-will-be-a-challenge/
i.e. pep 751: https://peps.python.org/pep-0751/
My thought: Why not OSGI metadata (capabilities and requirements with version ranges, optional/required deps, etc) to represent as one or more osgi bundles a given package's capabilities and requirements. Then the OSGi resolver...and the install/update services built upon it (e.g. eclipse p2, karaf features, etc)...could be use to validate the transitive closure of a package's dependencies and versions.
Using the rsa and py4j distribution provider, it would be very easy with rsa + py4j provider to build the Python->OSGi services...along with OSGi's dynamic creation of bundles containing python version/dependency information (from pep-071 eventually) and to have a service that could represent a full python application environment as a set of bundles, and then use the OSGi resolver to resolve them.
Beta Was this translation helpful? Give feedback.
All reactions