Packaging and python-for-android

[pf_moore (Paul Moore)]

Sorry, I’m really not sure what I can add. You seem to be trying to use pip in a way that’s very different from the intended usage, and without putting far more effort than I have time for into understanding how p4a works, I can’t see how your proposed “short/medium term” solutions would work.

@jtt

So it would be nice to figure out some intermediate solution for that which is nice enough, I suppose p4a parsing pyproject.toml’s build_requires manually could work but is this really the best approach? If with wheels caching this can work in a more pip-controlled (rather than p4a-cnontrolled) way if we just set up the folders right, that’d be nicer

I honestly have no idea what you mean by this paragraph, sorry.

[jtt]

I was referring to the questions regarding the wheels here: Packaging and python-for-android specifically regarding the non-platform-specific wheels you mentioned. I hoped you could possibly answer them, giving me some clues on how to make this work in a nicer way

I understand however if these are too unspecific, weird, or you lack the time. I can wait, or we can also abandon this for now. This would of course not exactly make it easier for me, but it’s not like I can change anything about that (or expect infinite help to address this)

[pmp-p (Paul P.)]

@jtt, no i won’t file an issue for that, i had a look and there are still too many changes involved in cpython core - especially - on dynamic module packaging/loading or cross compiliing to get something usefull.

So now, i already have some proof of concepts tools but i think it’s best to wait for the beeware mission to produce something usefull first - hopefully easy to use - then re-evaluate. Because at current state neither I can’t see how any “wheels” solutions would work apart from unpacking and repacking them with a constant knowledge of application layout which seems hard to get until a standard is established.