-
Notifications
You must be signed in to change notification settings - Fork 506
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
Refactor dependencies and their tests #1686
Conversation
For macOS, now dependencies are handled via
|
This has left me with lots of questions!
|
Tackles #. Supersede #. * setup.py * Remove false dependencies: virtualenv or sh * Add Cython, on behalf of p4a. Could be removed when p4a is updated. * Add sphinx for docs, pytest for tests, and kivy-ios for ios builds. * Flake8 fixes * android.yml * Stop installing Cython so setup.py can be tested. * Stop making installs editable. Unnecessary and deprecated by PEP. * Remove false dependencies: automake, and ssl hacks * Give job's names at the right level of abstraction. * ios.yml * Stop installing Cython so setup.py can be tested. * Stop making installs editable. Unnecessary and deprecated by PEP. * Remove false dependencies: cookiecutter and pbxproj * Specify [ios] so dependencies are correctly installed. * Give job's names at the right level of abstraction. * Dockerfile * Make Cython version match setup.py. * I don't understand Docker enough to know whether this runs setup.py, so I don't know if cython is required here or not. * tox.ini * Simplify by assuming py3 * Installation.rst * Move the pip install buildozer instruction into individual sections, so we can specify [ios] * Stop claiming Buildozer will work on earlier versions. setup.py explicitly rejects them. * Stop recommending to upgrade pip. If Buildozer needs a particular minimum version of pip, it should say so in setup.py. * Stop recommending to install Cython or virtualenv manually. * Minor copy-edits.
Rolling back to change to allow other changes to be merged while this one is resolved.
d34cc94
to
8e2e2d2
Compare
Good question. We likely need to investigate if all 3 dependencies are still really required (I think is a YES for
IMHO ( and that's why I started a long time ago the prerequisites management via In my plans, the automated prerequisite management was a strategy to apply on both So, the reply is: Yes for now, but I really would like to get rid of it.
Yeah, since prerequisites are already handled when running on macOS (even if does not cache the result and impacts the build time) I hope you now have a better view of the long-time plans. (and feel free to propose changes / make suggestions) |
That did help a lot. In the short-term, to keep the momentum up, I have added auto-make back to the yaml script and also added it to the docs. I appreciate this isn't the long-term goal. |
I am mulling over the goal. My observation is that the whole Buildozer eco-system is about bootstrapping up until you get a build. The YAML scripts are installing enough to get the PIP system going. The PIP system is enough to get Buildozer going. Buildozer tries to installs all the SDKs, NDKs, and p4a/kivy-ios/xcode requirements to get the build happening. p4a's recipes get the 3rd party libraries available for the final build. So, one thought is: if p4a is going to become responsible for installing all the requirements of its recipes, why doesn't it handle the Android SDK, NDK, etc. itself too? Do we have two parts of the system both responsible for the same issue: prepping the dependencies for a build? How will that task be divided up? Buildozer can't guess what future recipes will require. Should there be a handshake process where p4a reports the dependencies it will need, so Buildozer can install them? One reason not to like that, is that p4a can be run stand-alone without Buildozer. I have had concerns about having a program install pip packages and parts of the OS, while still running. The pip team's discussion boards seem dead against this. It seems to be working, to date. I have been wondering if p4a and/or Buildozer will eventually need to have two passes - one to homebrew/apt-get/pip install/venv all the dependencies, and then spawn another process that runs in the next environment to do the actual work. But when I think about that, I think the division is already there - Buildozer sets up for p4a. If that is the architecture, it would be good for Buildozer to be able to determine what is needed for a recipe. |
If you're OK with that, I'm going to summarize this discussion, on a separate issue (so can continue even after this PR is merged), in order to involve other contributors, core devs and users. This is a game-changing decision to take, that could help to easily maintain |
One final thought: It might be sufficient/a stepping stone for the p4a recipe system to check that the dependencies they need are installed, and if not, simply fail with a clear error message telling the user they need to install it. Not as swish as installing as having the Buildozer/p4a system install the dependencies itself, but should be enough to reduce the support requests as beginners are given clear instructions on what they need to do to fix their own systems. |
Despite conversation about future goals, this should still be merged now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thank you!
Addresses #1685 .
Supersedes #1515.
setup.py
android.yml
ios.yml
Dockerfile
test_python.py
tox.ini
Installation.rst
pypi-release.yml
build
rather than callingsetup.py
, and thus avoiding a deprecation warning.