This would require building our own python2 version with that patch applied. That would probably cause some package version issues since this would be a custom version.
Folks, could somebody please review this so we can upload and use this snap for field engineering purposes in customer projects?
Both @alitvinov and I are from the Canonical Field Engineering team - it is quite pressing for us to have this in the store so that the snap can be downloaded via proxy servers in confined environments.
@dmitriis - note that classic doesn’t require a voting process but we need to understand the issue and vet the publisher. It isn’t clear to me why you need classic as there is an upstream patch to python 2.7 for precisely this. There is also the ability to pick up the work to modify snapcraft-preload and I don’t see any mention of attempting that route.
Are you using stage-packages for python2.7? Have you considered an SRU to ptyhon2.7 in Ubuntu that includes the patch @sparkiegeek mentioned?
The upstream patch is not applicable to python2.7 as is. It seems small but it is not because it applies on top of this rework that went into 3.4:
So, yes, the patch below is 3 lines of non-comment changes but it relies on a huge rework which will not be SRU-ed for sure in my view. This is likely the reason for those changes not being in 2.7 upstream in the first place.
git --no-pager tag --contains=84ed9a68bd9a13252b376b21a9167dabae254325
v3.4.0
v3.4.0a2
v3.4.0a3
# ...
Our main criterion right now is time and we have a goal of getting a minimum viable product that we can use for a narrow use-case. We have already spent a lot of time on trying to use python3 and failed because the target software (rally) does not fully support python3. I applied several patches on top of rally to go forward with using python3 but I stopped doing that after 5 or so patches.
With the python patch not being applied upstream for 2.7 I do not think it is worthwhile to even try an SRU.
We are using python2.7 as a stage package because there is no python2 in the core snap.
In all seriousness, we do not have time to fix the underlying toolchain and runtime problems if they are not blockers because other customer work takes priority if we spend too much on trivial things like running a multi-process python application (it is not our call to allocate time for this, sorry). If usage of classic confinement was a blocker issue that work would get priority and we would work on it - but this is not the case.
Now that I described the problems in more detail could you help us to proceed with vetting?
I’ve vetted the publisher and granted use of classic. I’d like to see this use case supported in strict mode (perhaps via snapcraft-preload), but it unfortunately isn’t yet.