Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project's setup.py is not run, it should be (at least as an option) #1488

Closed
ghost opened this issue Nov 23, 2018 · 4 comments
Closed

Project's setup.py is not run, it should be (at least as an option) #1488

ghost opened this issue Nov 23, 2018 · 4 comments

Comments

@ghost
Copy link

ghost commented Nov 23, 2018

The main project's setup.py is never run. This breaks projects that need to be installed to work. I think this is wrong and should be changed, at least with an optional p4a option - the recipes can be installed beforehand so running the setup.py shouldn't trigger any misguided non-reciped dependency installs, so I don't see why this couldn't be done.

(My current workaround to this is to copy the entire project into another folder and specify it again as a dependency - but that's kind of hacky and I also ran into #1487 )

Versions

  • Python: all versions affected
  • OS: ubuntu docker
  • Kivy: not used
  • Cython: not relevant
@inclement
Copy link
Member

The current behaviour is essentially a deliberate choice to keep things simple, but it's definitely open to a rethink.
Perhaps we should support entry points, that probably wouldn't be very hard. So the setup.py could define an entry point android_main or something, which p4a uses if available.

@ghost
Copy link
Author

ghost commented Dec 3, 2018

The current behaviour is essentially a deliberate choice to keep things simple, but it's definitely open to a rethink.

Yes, please! Because this is why p4a is a huge headache for me, and why I pile up so many pull requests. I think defaulting to such simplifications is wrong - and I mean almost always.

Don't get me wrong, we need those hacks. Projects need them, recipes need them. The problem is, these hacks break things. And there is no way to turn them off without recipe, which a non-broken project fundamentally just shouldn't need. (IMHO) So they just should be opt-in.

Example of the headaches of this no setup.py issue:

E.g. to work around this issue, I need to add the project itself as a dep so it is build. However, just adding the project folder will make p4a think it has a recipe, since it's the project itself, which messes up Cython and more - so I need to copy it to a duplicate folder, and put that as a dependency. But then I had to find out how to fix file path deps first. Can you imagine how long it took me to figure all of that out...?

I just don't think this is good. Let python tools do their work: 1. lowers entrance barrier (less need to learn p4a quirks), 2. doesn't make some builds impossible without fundamental hacks, 3. recipes are needed for "picky"/broken projects anyway

But that's just my opinion, of course!

Edit: sorry, derailed more into general project goals than your question probably intended 😬 I hope it's useful input nevertheless

@ghost
Copy link
Author

ghost commented Dec 3, 2018

Also let me add it's completely not obvious to any python expert even, that the setup.py will simply not run. p4a spews out so much output, how is anyone new to it supposed to see that? One basically needs to decipher at runtime, while just running it per default is more likely to crash at build (=earlier, at a point where you can see the backtrace much easier)

@ghost ghost self-assigned this Jan 15, 2019
@ghost
Copy link
Author

ghost commented Jan 31, 2019

This will be fixed once #1625 is merged

This issue was closed.
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

No branches or pull requests

1 participant