Thanks!

I wasn't really sure if this will be that useful, but the implementation is very clean and I've nothing against it if people want such a feature.

Would you be willing to add something in the docs about it (i.e. at https://github.com/kivy/python-for-android/tree/master/doc), as well as just the docstrings? I think it will just get forgotten about it if isn't clear that the feature exists. I'll try to add that doc myself if it's a problem at all.

Updated recipes.rst, not really a fan of rst so hopefully the formatting is ok. Feel free to modify as needed.

@frmdstryr Thanks, it looks like it should be fine. I probably won't have time to check it fully for a few days, but I haven't forgotten about it, and hopefully should get to it at the weekend.

The code looks fine in principle, but I have some reservations.

For a start I'm not sure this solution is really justified by the original motivation about well defined recipe versions. I don't disagree that versioned recipes is at least a small problem, but in practice it's never been an issue, and most of the examples in the original report (#1115) target master branches for a reason. That raises the question of what this PR adds, and I guess the answer is that the ability to easily distribute recipes via pip is a nice thing on its own, regardless of whether it really helps with recipe versioning.

However, I'm concerned that this may introduce recipe fragmentation that causes more problems than it solves. There are examples in the recipes you have already published: your fixed numpy recipe is great, but why not just do a PR with these fixes for p4a itself? Since the pip recipes override local p4a ones, anyone who has installed p4a-numpy won't get the benefit of new updates to p4a unless p4a-numpy is itself kept up to date with them. The same is true of e.g. your p4a-crystax package, which overrides the builtin python3crystax but doesn't actually change it. I'd be very happy to have a python2crystax in p4a master instead, would you be interested in adding it there?

For what it's worth, there's actually already a way to use local recipes in p4a builds without cloning p4a, using the --local-recipes argument (defaulting to a p4a-recipes folder in the current directory). Do you know about that? I guessed that you did, but actually I realise it isn't really documented. That's my mistake, I'll add some documentation about it shortly.

I see your (very good) points and agree it may lead to fragmentation. I guess it just depends on what people prefer.

I've just been using this so I can have travis-ci install and test builds with the exact versions needed for my apps (and its easier to update apps shared with other uses when they can just pip install and rebuild). I don't have to worry about fixes for one app breaking another.

Do what you think is best. Perhaps others can chime in.

The python2crystax recipe is actually a copy of #707 with just the versions updated, so it's nothing new. I didn't want to do a pr because it requires a lot of changes (ex every python2 compatible recipe needs updated to add python2crystax) among multiple other changes (which I forget) in the core. Also start.c is not compatible with python2 and python2crystax, which I think is risky (and finally the original PR was never merged).

If I may give my opinion. It's true that it will bring fragmentation, but it still looks a very nice to have feature to me. Indeed not for necessarily for #1115.
The main reason being it's a great way to share recipes with others and across projects even before they get merged to p4a.
It may also make it possible to do some matrix testing in Travis-CI trying one version of a recipe with another. Not sure that's a very valid point though.

Of course it using upstream recipes would always be the recommended for the reasons @inclement brought up. So we could emphasis on this in the documentation and also display a warning in the console every time a user use such recipe.

@AndreMiras that's a good idea. I added a warning.

Also, I can rename the packages I created to use a different prefix (or transfer them to the kivy group) to avoid confusion. Perhaps the p4a- (or some other) prefix should be reserved for "core" packages and another prefix be suggested for "community" packages.