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

Question: compatibility with cx_Freeze #478

Closed
xyztdev opened this issue Oct 20, 2015 · 6 comments
Closed

Question: compatibility with cx_Freeze #478

xyztdev opened this issue Oct 20, 2015 · 6 comments

Comments

@xyztdev
Copy link

xyztdev commented Oct 20, 2015

Currently, I have an application that should run on android and windows. I am building my windows version with cx_Freeze because:

  1. It supports the standard distutils setup infrastructure
  2. It is cross-platform
  3. It is maintained

The buildozer personally bothers me because it uses its own system rather than the standard distutils.

cx_Freeze adds an Executable class to determine which scripts are the main entry points. What I am wondering is this: if I were to implement the bdist_apk command with the cx_Freeze Executable class (if cx_Freeze is installed) so that I would be able to use one setup.py file to build everything and submit a pull request, would this be accepted? It would only be active if cx_Freeze is detected, and would make things so much simpler on my part.

@inclement
Copy link
Member

Do you have an example of what your result might look like? I don't know much about cx_freeze. I vaguely intended to implement a bdist_apk in what's presumably the same kind of way though.

@xyztdev
Copy link
Author

xyztdev commented Oct 20, 2015

The setup script for cx_Freeze is similar to this:

import sys
import os
from cx_Freeze import setup, Executable

# Dependencies are automatically detected, but it might need fine tuning.
build_exe_options = {"packages":["keyring"]}

setup(name = "Name",
        version = "0.1",
        description = "Description",
        packages = ["package"],
        options = {"build_exe": build_exe_options},
        executables = [Executable("package/main.py")])

To build for windows, I run python setup.py bdist_msi

My implementation would be something like this:

try:
    from cx_Freeze import Executable
    class BdistAPK(Command):
        description = 'Create an APK with python-for-android'
    user_options = []

        def initialize_options(sel):
        # Initialize options

        def finalize_options(self):
            # Finalize options

    def run(self):
            initScript = self.distribution.executables.initScript
        # Call the ToolchainCL with info.

except ImportError:
    # Use the current (non-working) implementation.

Basically, if the user has cx_Freeze installed, the user will be able to use python setup.py bdist_apk. If not, nothing will be affected. If you want, I am willing to provide an executable class with similar parameters to the cx_Freeze executable class so that any user can run python setup.py bdist_apk even if cx_Freeze is not installed.

@inclement
Copy link
Member

How would you set all the different options? As arguments to the Executable-like class, or to setup, or some other way?

@xyztdev
Copy link
Author

xyztdev commented Oct 20, 2015

Well, let's look at the different options:

python-for-android apk --private /path/to/your/app \ --package=org.example.packagename --name="Your app name" --version=0.5 --bootstrap=pygame --requirements=sdl,python2 --dist_name=testproject

  1. The private would be set from the package location.
  2. The package would be set from possibly the name and the author.
  3. The name would of course be set from the name
  4. The version ditto from the version
  5. The bootstrap from the Executable
  6. The requirements from the build_apk_options["packages"] and some autodetection.

Basically I would reuse the format so that the same setup script could build both the msi and the apk.

@inclement
Copy link
Member

This seems largely ideal for what I thought bdist_apk should probably be (though all those settings should be manually configurable as well), so this sounds good to me. It would be great if you were to implement a full cx_freeze-like api that doesn't depend on anything else. If this would be significantly harder than depending on cx_freeze, then I'd be happy to merge a cx_freeze-depending version first and leave the rest for later.

@inclement
Copy link
Member

I'll close this now since it's not really an open issue.

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

2 participants