Add a developer mode

[eliasdorneles]

Briefcase installs the platform requirements defined in the setup.py file.

For someone using briefcase-template, for example, this means that it will pip install into the $PLATFORM/app_packages directory the packages defined in the setup.py.

It would be nice to have a "platform developer mode", which would use a local version of those packages (specially useful for someone working on Toga).

One idea to implement this would be to provide a way of configuring alternative local versions for the requirements there, e.g.:

python setup.py TARGET --overrides package-overrides.json

And then, package-overrides.json could have something like:

{
    "toga": "/home/elias/src/toga/src/core/",
    "toga-android": "/home/elias/src/toga/src/android/"
}

This information would then be used by the install_platform_requirements function to feed pip the package names with the overrides applied.

[Ocupe]

@eliasdorneles I would love this addition! However I would prefer a shorter syntax like:

python setup.py TARGET --dev

I would be nice to not have to write a json file and just take the packages from the venv. With json file could be a advanced feature but I think the default should be as simple as possible. With this being sad I have no idea how to make it a reality :).

[freakboy3742]

@Ocupe @eliasdorneles and I talked about this - the problem is that your local venv won't have all the packages you need. For example, if you're developing for Android, you won't have toga-android installed locally.

So it's not enough to just say --dev (which I agree would be a preferable usage) -- you have to provide paths for all the dependencies you want to install from local sources as well.

That said, since end users are unlikely to have multiple development versions, we could say that --dev will always look for a requirements.dev file.

[freakboy3742]

As for how to implement this - I don't think it will be that hard. install_app_requirements() and install_platform_requirements() both pass in a list of requirement strings. Each string needs to be parsed to extract the version identifier (if provided); that then gives you a raw list of packages. If requirements.dev file then lists packages and paths:

toga-core /Users/rkm/code/toga/src/core/toga
toga-cocoa /Users/rkm/code/toga/src/cocoa/toga_cocoa
colosseum /Users/rkm/code/colosseum/colosseum

you can filter the list of installed packages to only include files that aren't overridden; and then create symlinks using the directories specified for all the remainder.

[freakboy3742]

Or... even better... don't symlink - pass in the local directory to the pip install process.

[ramiroluz]

@eliasdorneles @freakboy3742 @Ocupe
I did something like this, parsed the file requirements.dev then I searched by the "key" on the lists:
distributions.install_requires and app_requires to override the names.

But some dependencies are "collected" from the package and are not in any list.

For example, the dependency toga-core come from toga-gtk. toga-gtk is on the list, toga-core is not.

So, if you want a local toga-core would be more difficult to get this done.

[eliasdorneles]

@ramiroluz would you mind sharing what you've got anyway? I'd love to give it a try. :)
Thank you! <3

[ramiroluz]

Ok, I will finish my idea, that is, everything that is declared in the dev-file will override the dependencies on the lists. Everything that is not on the lists but explicitly declared on the file will be appended to the app_requires list.

[ramiroluz]

Done, @eliasdorneles what do you rater prefer:

• Review the changes in my fork?
• Or want me to do a PR?

[eliasdorneles]

Hey Ramiro, a PR works best, I use scripts to check out code from PRs, and others maintainers can have a look as well :) Don't worry, a PR doesn't need to be final, experimental PRs have a special place in my heart. :) Thank you!

…

On Oct 13, 2017 11:29 AM, "Ramiro Batista da Luz" ***@***.***> wrote: Done, @eliasdorneles <https://github.com/eliasdorneles> what do you rater prefer: - Review the changes in my fork? - Or want me to do a PR? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#73 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACSvVtbwGe0d1c3jnxqoQ9Ytt91t9zyks5sr3PDgaJpZM4PdXOF> .

[ramiroluz]

Something is wrong: https://beekeeper.herokuapp.com/projects/pybee/briefcase/change/179aab8e-7a6d-46b0-ba83-b3f55c9ebe7b/build/2d51f781-80f5-45f2-8b09-a58774f96c86/task/smoke-test

[freakboy3742]

@ramiroluz That log indicates that the test suite wasn't able to start. That suggests there's something wrong with the PR itself - possibly a syntax error in a test file, or something hasn't been checked in.

Beekeeper just runs python setup.py test in the root of the GitHub repository checkout - so if that doesn't work locally, it won't work on CI either. If you need other arguments to be passed in, then you'll need to modify the beekeeper script to account for that.

[ramiroluz]

I found the problem with a friends help. @cassioborato figured out that I was using the mock external lib. Then I fixed to use the unittest.mock stdlib.

…

On Sat, Oct 14, 2017 at 2:10 AM, Russell Keith-Magee < ***@***.***> wrote: @ramiroluz <https://github.com/ramiroluz> That log indicates that the test suite wasn't able to start. That suggests there's something wrong with the PR itself - possibly a syntax error in a test file, or something hasn't been checked in. Beekeeper just runs python setup.py test in the root of the GitHub repository checkout - so if that doesn't work locally, it won't work on CI either. If you need other arguments to be passed in, then you'll need to modify the beekeeper script to account for that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#73 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAR5NnfKsbJqdXNFdZ3LseJY_dUt_C3Uks5ssEI_gaJpZM4PdXOF> .

-- -- -- Ramiro Batista da Luz -- (41) 9173-2231 -- http://www.ramiroluz.eti.br

[jedie]

And a development mode is what I was looking for, but didn't know it until beeware/toga#315 (comment) ;)

Is it not just that running setup.py install platform requirements via pip with '--force-reinstall' ?

See: https://github.com/pybee/briefcase/search?q=%27--force-reinstall%27

e.g.: if toga installed as "editable" from github source, then it will be replace with the last PyPi package version, see: beeware/Python-Django-template#2 (comment)

Wouldn't it be the easiest thing if we just remove --force-reinstall away?
Then a developer can install the platform requirements by himself from source and can then run setup.py?

Installation from source is just something like this:

git clone https://github.com/pybee/toga.git
pip install -e toga/src/core
pip install -e toga/src/dummy
pip install -e toga/src/django
pip install -e toga/src/android
...

I will try this and report back.

EDIT:

Wouldn't it be the easiest thing if we just remove --force-reinstall away?

I have just tried it and now I see that this is not enough :(

OK, what's about something like this:

We "look" into "pip freeze" in all install_*_requirements() functions and install the requirement in the same way?

[jedie]

I tried a POC here: #111

[freakboy3742]

The 0.3 branch now includes a developer mode.