Modifications to the system Python can adversely affect charm execution. We could avoid this by including Python inside jujud. This would involve some plumbing to statically build Python for each target architecture, but might be worth mulling over.
1 Like
Do you have examples of problems that this would solve? Juju already needs a bunch of specific support for each operating system that it runs workloads on, so it’s not like people are already throwing charms at arbitrary distributions and finding that a Python variation is the sole blocker.
Embedding Python has a number of downsides, including making it difficult to use things like python-apt (which is tied to the system’s apt version as well as the Python version), and requiring frequent Juju updates to keep up with Python security updates (and OpenSSL etc. security updates, if you really are statically linking it). Distributions exist for a reason, and it doesn’t seem like bypassing them here provides value.
1 Like
I think we can add more checks when python is required to expose warnings back to the user. Specifically what issue have you seen @timClicks? This would be a good starting point to put in checks for.
Good questions. I noticed that someone had added this line of advice in First steps with the Operator Framework.
Check that the top of the
charm.pycontains#!/usr/bin/env python3.
It strikes me that if we’re concerned that charms might be executed by the wrong interpreter, perhaps we should take that problem away by design?
Must admit that this isn’t a fully-fledged idea by any means!
I think that we’re currently doing the most Pythonic thing, which is to run code in a virtual environment. If somebody is running into trouble because of a modified base Python binary, I think that they are either installing software that is not modeled inside of Juju, or attempting to stuff two conflicting charms onto the same unit.
The solution to the first problem is to write a charm to model the software inside of Juju. The solution to the second is to use the built in Juju primitives to isolate the software on its own unit, using lxd containers where it’s not appropriate to dedicate an entire physical (or virtual) machine to the software in question.
I think that this keeps us in territory where we’re suggesting doing the “right” thing, from both the point of view of someone who is experienced with Python and someone who is experienced with Juju, without becoming responsible for maintaining and updating our own Python binary inside of Juju.
i totally agree that those techniques, such as deploying units inside containers, is the _right_way to do things. But that’s not to say that people start their time with Juju with best practice.
It’s the user who knows the least who would benefit the most from the change I’ve described.
I understand your point, and I think that it’s a valid concern.
I’m just cautious about a plan that would add extra MB to the Juju daemon, and add more complexity to our build process, to do something that would feel wrong to me, were I an experienced Python person coming to Juju for the first time, even if it would help someone who was not experienced in either.
I’m not sure either. It’s difficult to know how big the problem is - because people who muck up their environments are likely to throw their hands up and walk away.