Skip to content

when listing distributions, if one has no ndk_api, consider it to be 0#1494

Merged
tshirtman merged 6 commits into
masterfrom
fix_ndk_old_distributions
Dec 14, 2018
Merged

when listing distributions, if one has no ndk_api, consider it to be 0#1494
tshirtman merged 6 commits into
masterfrom
fix_ndk_old_distributions

Conversation

@tshirtman

Copy link
Copy Markdown
Member

this avoids crashes, but also ensure that it doesn't consider it a
match, is that something we want?

this avoids crashes, but also ensure that it doesn't consider it a
match, is that something we want?
@tshirtman

Copy link
Copy Markdown
Member Author

@inclement @AndreMiras opinions welcome!

@tshirtman tshirtman requested a review from inclement November 26, 2018 18:56
@AndreMiras

Copy link
Copy Markdown
Member

Thanks for looking into this!
I thought we had a default value setup somewhere. But seeing Distribution.ndk_api is None that's probably not what I was looking for 😄
What about just totally skipping it when the key is not available, just like we did for 'archs' in dist_info above?
I haven't played with it so I'm not sure if that would make sense. @inclement is your man since he made a large refactoring on this recently.

@tshirtman

Copy link
Copy Markdown
Member Author

Yeah i was wondering about just setting to None, but i now think it's not going to make much of a difference, since this is only checked if user asked for a specific api, this way may trigger a few unnecessary distribution rebuild, and some unused space, but it's probably a lesser evil than trying to guess what api was used in an older distribution if we fail.

@DanShai

DanShai commented Nov 26, 2018

Copy link
Copy Markdown

Thanx @tshirtman your solution solved my problem !

@inclement

Copy link
Copy Markdown
Member

The intended solution is to delete and rebuild the dist as ultimately using a dist with an unknown API target can't be recommended, but this wasn't a major point. Setting a default value is acceptable, it may as well be zero. It would also be good to print a warning in this case.

@tshirtman

tshirtman commented Nov 26, 2018

Copy link
Copy Markdown
Member Author

Ok, i'll add a warning, would something like:

"Distribution {dist} has been built with an unknown api target, ignoring it, you might want to delete it".

represent the intention well?

@inclement

Copy link
Copy Markdown
Member

Sounds good to me!

"built with an unknown api target, ignoring it, "
"you might want to delete it".format(
distname=dist.name,
distdir=dist.dist_dir

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

distdir seems unused here

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I though it would make it easier for user to remove it… but i can remove it if it's not relevant.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No sorry what I mean is the format string seems to add a param that's not used, right?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea kind of looks like (distdir) should be {distdir}

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uh, i misread that >_<, thanks for your patience 😆

@ghost

ghost commented Nov 26, 2018

Copy link
Copy Markdown

Please note an ndk_api of 0 possibly breaks this line:

https://github.com/kivy/python-for-android/blob/master/pythonforandroid/distribution.py#L98
(or at least did for me, the ndk_api wasn't set somewhere but that made it default to 0 instead of None, but the distribution was detected to have an api version (not 0) so this condition broke it being located properly - you should evaluate carefully whether this can happen in this case as well, and whether this line needs to be adjusted)

This is why I made this pull request: #1484 just to provide some background

So I highly recommend against merging this unless you either address this, or you're certain that this won't be an issue (I might be wrong, obviously, I'm not sure either if this code path can be hit in this case).

@DanShai

DanShai commented Nov 26, 2018

Copy link
Copy Markdown

When it was None I got tons of errors and couldnt build the apk, but @tshirtman solution worked like charm ! 0 is better and buit the apk on the fly. if you woried bout that line just replace:
if ndk_api is not None --to--> if ndk_api
thats it and leave it at 0

@ghost

ghost commented Nov 26, 2018

Copy link
Copy Markdown

Right, that might be one way to address it, but then also the argument parser default value for --ndk-api (in toolchain.py) would need to be set to 0. My main intention was to point out that in the current form this pull request might clash with some things, not that None is the way to go or anything like that

@ghost ghost left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comment, with None sometimes being used for ndk_api instead of 0. I think it should be either None or 0 everywhere, not a mix of both (this broke things for me at one place, which is why I changed the --ndk-api default in a pull request recently)

@ghost

ghost commented Nov 26, 2018

Copy link
Copy Markdown

Another line that may need changing in relation to this pull request: https://github.com/kivy/python-for-android/blob/master/pythonforandroid/distribution.py#L215

Might be worth searching for ndk_api is None all over the code before going ahead with this change

@ghost

ghost commented Nov 26, 2018

Copy link
Copy Markdown

Hm. Thinking about this some more, why can't we fix the code that breaks handling None? It is obviously a special case, using 0 might risk running through code without warnings/errors that should actually care about the ndk_api... so I'm not sure this is the right direction. But I wrote too much already, I'll let you guys discuss this and figure something out

@tshirtman

tshirtman commented Nov 27, 2018

Copy link
Copy Markdown
Member Author

It's good feedback, i had looked at the line you mention and assumed that it wouldn't be an issue, but didn't think that ndk_api could be 0, indeed, that wouldn't be good, maybe setting to None would be better, that way we are sure this condition will evaluate to True and the distribution is not matched.

Anything against that?

@ghost

ghost commented Nov 27, 2018

Copy link
Copy Markdown

As elaborated above, I like None, but I can't claim to know all the potential consequences of this change 😬

@inclement

Copy link
Copy Markdown
Member

As a general note, this is important only for the handling of existing dists that predate the ndk_api setting. It should not be possible to create new dists with p4a that don't have an NDK API. The change here should be seen in that light: we don't want dists with a missing NDK API to actually work well (if at all), just to not crash p4a.

ghost
ghost previously approved these changes Nov 27, 2018
AndreMiras
AndreMiras previously approved these changes Nov 28, 2018
@AndreMiras

Copy link
Copy Markdown
Member

Thank you for clarifying @inclement then do we want to address it this way in this case?
I mean if at the end the apk is not going to work, why don't we fail fast with a meaningful error during the build? Rather than failing late at runtime?

@ghost

ghost commented Nov 28, 2018

Copy link
Copy Markdown

@AndreMiras I might be wrong, but I think the change here means that rather than the presence of an old, non-ndk build crashing p4a always, it will no longer disrupt build of a proper distribution with ndk version when any old distribution is still present - with this warning advising the user to remove that old outdated distribution, since it won't be built or be recognized anyway.

(at least if --ndk-api is specified, a distribution with .ndk_api being None would be filtered out by get_distribution in distribution.py. maybe an additional change could also ensure it's never picked up even when --ndk-api is unspecified, that might be worth an addition?)
edit: corrected func reference

Nevertheless, I think this pull request is useful, because the warning is much more useful than a random backtrace, and I also find it useful to not block building a more recent project just because an older, incompatible distribution happens to be lying around. But of course one could still abort the entire build always but with a nice error. However, I prefer the solution here (given I understood things correctly)

@ghost

ghost commented Nov 28, 2018

Copy link
Copy Markdown

@tshirtman what do you think about changing this line:
https://github.com/kivy/python-for-android/blob/master/pythonforandroid/distribution.py#L98
to this:
if (ndk_api is not None and dist.ndk_api != ndk_api) or dist.ndk_api is None:
?

(The idea being that a distribution with .ndk_api is not set is invalid, and this would ensure it's never picked up even when --ndk-api is unspecified by the user)

@tshirtman tshirtman dismissed stale reviews from AndreMiras and ghost via 8849850 December 2, 2018 18:28
ghost
ghost previously approved these changes Dec 2, 2018

@ghost ghost left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't actually TESTED it, but just code-wise this all looks reasonable to me.

@AndreMiras AndreMiras left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking good

@tshirtman tshirtman merged commit 95b3247 into master Dec 14, 2018
@tshirtman tshirtman deleted the fix_ndk_old_distributions branch December 14, 2018 21:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants