Requirements parsing undefined/ambiguous behavior

[UriyaHarpeness]

Requirements parsing undefined/ambiguous behavior

[Julian-O]

I think what you are proposing would be a good improvement.

What would be a better improvement would be to remove the limitations so they don't need to me documented - i.e. make p4a support ~=, <= and >= at a minimum.

(At the moment, version information is passed to the recipes via environment variables! Changing that to a more direct method might be a useful refactor too.)

[UriyaHarpeness]

By supporting ~= ,<=, and >= - do you mean treating them all as ==? Or implementing a mechanism to see which versions available support the specification?

The first I think is not very good, as it doesn't behave as expected probably. And the latter would mean more complication, possibly slower runtime, and if each package has its own requirements with different version - a dependency hell like can happen in pip, resulting in spending a lot of time trying to get everything to play well together,

Also, in the recipes, I don't see a version for the packages each recipe depends on, in another sense it just says "all of these packages work with all of the other packages in the current (latest) state", or am I missing something?

[Julian-O]

I definitely meant the latter. I hadn't considered the dependency hell issue - I guess I hoped it was delegated to pip to sort out.

[I pass on the second question - I don't know the answer.]

[UriyaHarpeness]

Seeing as many recipes have a .patch file, which depends on the code's content (and thus, its version) - I'd assume that the statement in the second question is true.

It may not be defined that way, but if a package changes the patch may not work, so each package has theoretically one supported version at a time.

And if that's the case, perhaps even == is not truly valid...

This is getting a bit complicated I believe.

How do you suggest we take it forward @Julian-O?

On an unrelated note - do you know when my PR might be reviewed?

[Julian-O]

@UriyaHarpeness : I wouldn't pin the success of this on my knowledge. I have never written a recipe.

I have idly thought before that recipes need to be totally refactored. They should be subclasses, not modules with weird, poorly documented assumptions. They should provide much more meta-data about what they are expecting, including versions that they are known to work with, versions they are assumed to work with and versions they are known not to work with.

They currently support two platforms (Darwin and Linux), but they should support more.

However, I am not expecting anything in that direction any time soon.

In the meantime, I think your original proposal would still be a step forward.

I have not got code review privileges (a state of affairs I think is very appropriate!) and I can't comment officially on when your PR might be reviewed. I know the core developer(s) are currently focussed on upcoming releases, so I would give it a couple of weeks before I started to ask for more attention.

[UriyaHarpeness]

Just to be sure - original proposal meaning the 3 steps I wrote in the issue's description?

[Julian-O]

Yes

If we can't handle the functionality a developer would expect, we should document it and (if we can) detect it and give a meaningful error.