I'm trying to package a script into a .dmg file using Py2App. When I try to open the packaged file, it immediately crashes.
I tried bundling the files in both Alias mode and regularly.
Alias bundling using python3 setup.py py2app -A
It generates a dist folder which contains the packaged application. I can't open the application directly, but I can open it by unpacking the file, and opening the Unix Executable File in the MacOS folder.
Opening the application this way works, along with all functionalities.
Regular bundling using python3 setup.py py2app
I can't open the application regularly, and even through the Unix Executable File when unpacked.
I'd appreciate any input I could get. Really not sure how to proceed from here.
Below are my setup. I'm not sure if I'm missing anything in setup.py? Please note I can open the file when I bundle the package in Alias mode, but ONLY when I unpack the app file in the dist folder.
File Structure
|-- assets
|-- logs
|-- scripts
|-- utils
README.MD
requirements.txt
setup.py <-- for Py2App
main.py <-- entry point
setup.py
from setuptools import setup
from glob import glob
"""
Description:
- Converts python script into .dmg file for macs
- Run "python setup.py py2app" in terminal to start
"""
APP=["main.py"]
DATA_FILES=[
('assets', glob('assets/*.*')),
('logs', glob('logs/*.*')),
('scripts', glob('scripts/*.*')),
('utils', glob('utils/*.*'))
]
OPTIONS={
"argv_emulation": True,
"iconfile": "assets/spdr.png",
"includes": ["os", "yaml", "concurrent.futures", "datetime", "time"],
"packages": ["pandas", "PySimpleGUI"]
}
# I tried not including includes, and packages from OPTIONS, and it doesn't seem to help either.
setup(
app=APP,
data_files=DATA_FILES,
options={"py2app": OPTIONS},
setup_requires=["py2app"],
)
Related
I'm trying to create a package (that includes several subpackages) for reuse and distribution. The plan is to provide a CLI entry point to allow easy launch. After building the package and installing it in a virtualenv, I get a ModuleNotFoundError for imports from the subpackages included in the main package.
I think this has something to do with setting the right paths in __init__.py, but having read multiple examples on the web, I'm still rather confused as to why anything should go in __init__py and what that something is.
The package is built so that the package name (and thus folder created in site-packages) is the same as the root in the directory structure below.
The directory structure is (simplified and with names changed):
mypackage
|- __init__.py
|- entrypoint.py
|- subpackage1
|-- __init__.py
|-- module1.py
|- subpackage2
|-- __init__.py
|-- module2.py
Note that all the __init__.py are empty
And entrypoint.py is:
from subpackage1.module1 import foo
from subpackage2.module2 import baz
if __name__ == "__main__":
pass
In my pyproject.toml, I define:
\[project.scripts\]
mypackage-cli = "maypackage:entrypoint"
After installing with pip, I run (in a virtualenv where I pip installed the package):
(myvenv) me#mymachine ~ % mypackage-cli
But I get:
ModuleNotFoundError: No module named subpackage1
Two things to note:
When running source locally, I have no issues
If I edit the files in site-packages to have from mypackage.subpackage1.module1 import foo I don't get the error anymore when running the installed package, but then when trying to run the same modified imports (i.e. changing to import mypackage.subpackage1.module1) locally in my dev env, I get a ModuleNotFoundError
What's the correct way to get the imports to work when packaged and when running locally in my dev env?
Thanks!
Your "top-level importable package" seems to be mypackage so all your import statements should start from there. For example from mypackage.subpackage1.module1 import foo.
In order to avoid confusion between "local" and "installed" (in site-packages), I recommend you to use the so-called "src-layout" for this project's directory structure. In combination with the "editable" installation, it is very convenient to work with.
I would like to create a macOS app using py2app. My application (testapp) has a few dependencies
(paramiko,scp,PyYAML,PyQt5). To do so:
I installed python3 using brew (located in /usr/local/Cellar).
I installed the aforementioned dependencies in this python
I ran python3 setup.py py2app --packages paramiko,yaml,scp
Everything runs apparently fine. I have a testapp.app directory created in dist. However, when I run the python located in the bundle (./dist/testapp.app/Contents/MacOS/python) I run into troubles. Indeed, I can import the aforementioned external packages but when I inspect their path, the result gives me the local installation and not the one of the bundle.
For instance paramiko.__path__ gives me: /usr/local/Cellar/python3/3.6.3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/paramiko
Looking deeper into the bundle, I could not find the file site-packages.zip which should be created by py2app.
As such my bundle is absolutely not self consistent and can not be distributed on other machines. Would you have any idea about what is wrong with my setup ?
EDIT: I forgot to mention that I started to inspect the embedded python because running the embedded app failed.
Compiled and installed ejabberd version 15.10 on ubuntu 14.04 machine in /opt/ejabberd directory.
In the older version the module can be compiled directly with erlc command and then pasted to ejabberd module dir(or symbolic linked) which was very efficent way to develop the modules.
But after upgrading to newer ejabberd version when using the INFO_MSG()/2 from logger.hrl the ejabberd fails to load the module.
When compiled by placing the module file inside the ejabberd src directory and running make in ejabberd directory as suggested at https://www.ejabberd.im/ejabberd-13.10 and ejabberd how to compile new module the module works.
But this is very inefficient compared to the older method of compiling and running the modules with elrc command directly.
Is the latter approach the right method, if so why was it changed and where are the official docs that explain compiling with latter approach.
you can compile ejabberd module like this
erlc -I /lib/ejabberd/include -o /lib/ejabberd/ebin /home/sunil/Documents/ejabberd_custom_modules/mod_profile.erl
In this example /lib/ejabberd/include is header file (.hrl) path , /lib/ejabberd/ebin* is binary file path of ejabberd and '/home/sunil/Documents/ejabberd_custom_modules/mod_profile.erl is source file path.
Right way to compile your custom ejabberd module (suggested by process-one) is :-
put your module into ejabberd/src folder.
come to ejabberd directory in terminal and run command $ sudo make
it will show you that your module is compiled. You can check ebin directory for .beam file that is result of your compilation.
Now to run your module
$ sudo make install
Add your module into config file at /etc/ejabberd/ejabberd.yml
restart your ejabberd and your custom module will be running.
Another way of compiling with erlang shell is :-
start your erlang to load all included files required by ejabberd module from ebin directory.
> erl -pa <your path to ejabberd/ebin>
You can also give multiple paths separated by space if you are including files from multiple places. Like
> erl -pa <path1/ebin> <path2/ebin>
This will start erlang shell. Next things you need to do are :-
do
> cd("<path to your module.erl file>").
compile your module
> c(your module).
Your module.beam file will be generated as a result of your compilation.
The dart page http://pub.dartlang.org/doc/#adding-a-dependency describes how you can have a dart file (parser_test.dart) import files from its own package using the 'import "package:..." style of import. It seems to imply this is a good thing - better than using relative paths. This example shown is for a file in test which appears to be special. But, then why does it not make sense for importing same package lib files from a lib in the package. Maybe it does make sense, but if so the pub update does not make it convenient.
foo/
/lib/
foo_lib_1.dart
foo_lib_2.dart
src/
foo_lib_1/
foo_lib_1_impl.dart
foo_lib_2/
foo_lib_2_impl.dart
Assume foo_lib_2 uses foo_lib_1. There are two options for foo_lib_2.dart:
import "../foo_lib_1.dart";
import "packages:foo/foo_lib_1.dart";
My guess is the suggested approach is the first for any such import that resides under lib. The reason I think this is pub update seems to automagically provide a soft link in the packages folder of any of bin, test, or example to foo, like foo -> ../lib. Yet, it does not do the same for the packages folder in top level foo. This means to get the second type of import (i.e. the packages import) to work you need to add:
foo:
path: lib
to the dependencies of foo in the pubspec.yaml. Is there any advantage or disadvantage for a library to use the package style import to import another library (not in test, bin, or example) from its own package? Is there a reason for the apparent inconsistency?
After accepting the answer below, I still am not seeing it. Here is what I'm seeing in a shell session and I would like to reconcile this behavior with the answer. Any explanations appreciated. I am using emacs instead of DartEditor, thus the old-school command line approach here.
### Show all files, one dart library file and one yaml, plus empty
### lib and test folders
user#user-thinkpad:/tmp/uml_codegen_sample$ ls -R
.:
lib pubspec.yaml test
./lib:
plusauri.dart
./test:
### Show contents of pubspec
user#user-thinkpad:/tmp/uml_codegen_sample$ cat pubspec.yaml
name: domain_model
version: 0.0.1
description: >
Auto-generated support from /home/user/plusauri/modeling/plusauri.xmi.json
dependencies:
ebisu:
path: /home/user/open_source/codegen/dart/ebisu
### Run pub install and show the changes. Note there is a soft
### link to packages from test, but not lib.
user#user-thinkpad:/tmp/uml_codegen_sample$ pub install
Resolving dependencies...
Dependencies installed!
Some packages that were installed are not compatible with your SDK version 0.4.7+5.r21658 and may not work:
- 'pathos' requires >=0.5.0+1
You may be able to resolve this by upgrading to the latest Dart SDK
or adding a version constraint to use an older version of a package.
user#user-thinkpad:/tmp/uml_codegen_sample$ ls -R
.:
lib packages pubspec.lock pubspec.yaml test
./lib:
plusauri.dart
./packages:
domain_model ebisu pathos
./test:
packages
### Note here the program does not work, and suspiciously pub
### install put no packages link under lib like it did test
user#user-thinkpad:/tmp/uml_codegen_sample$ dart lib/plusauri.dart
Unable to open file: /tmp/uml_codegen_sample/lib/packages/ebisu/ebisu_utils.dart'file:///tmp/uml_codegen_sample/lib/plusauri.dart': Error: line 5 pos 1: library handler failed
import "package:ebisu/ebisu_utils.dart" as EBISU_UTILS;
^
### Copy the same dart file to test to show that it can run there
### just fine
user#user-thinkpad:/tmp/uml_codegen_sample$ cp lib/plusauri.dart test/
user#user-thinkpad:/tmp/uml_codegen_sample$ dart test/plusauri.dart
Main for library plusauri
user#user-thinkpad:/tmp/uml_codegen_sample$
### Finally, manually create the soft link in lib, to show it will
### then run
user#user-thinkpad:/tmp/uml_codegen_sample$ ln -s ../packages lib/packages
user#user-thinkpad:/tmp/uml_codegen_sample$ dart lib/plusauri.dart
Main for library plusauri
Actually, you can definitely import using the package:foo/foo_lib_1.dart syntax without needing to change your pubspec.yaml or even creating a pubspec.yaml in the first place!
You can see that this is true from a language level, in this test: https://github.com/dart-lang/bleeding_edge/blob/master/dart/tests/standalone/package/packages/package1.dart
and an example of this in the wild is: https://github.com/kevmoo/hop.dart/blob/master/lib/hop_tasks.dart#L17
I do not think there is any benefit from writing one way or another except that writing relative paths is slightly shorter.
From a project structure point of view, I would use relative path imports when I am drilling into subdirectories that are not going to be exposed to the user. src is generally seen as implementation specific details that won't be visible to external users, so use relative paths to your heart's content.
However, if you're working within multiple directories, then you should use package: imports to reinforce the idea that the parts are stand-alone and interchangeable. Within the lib directory itself, you want to say that these two libraries, although they might rely on each other, can live separately and are not bound by their physical location.
I would recommend not ever using ../ in your imports, as that is fragile and may break in strange ways if/when you modify directory structure or deploy.
In my project, i want to use mysql so i checkout this https://github.com/dizzyd/erlang-mysql-driver. I want to know how install the application so that my project can interact with it
Have a look at "rebar" - https://bitbucket.org/basho/rebar/wiki/Home
It can be used for installing dependencies, and for creating independent releases.
And a quick look at erlang-mysql-driver, that you want to use, shows that it is also using rebar for its dependency management.
rebar may complicate things if you have already started laying out your app (done some coding already) or if you are a newbie , however, if your project is an erlang/OTP app, then i suggest that you first organize you code according to the recommended file system like this:
MyProject--/src
/ebin
/lib
/include
/priv
/doc
/examples
/test
/Emakefile
The Emakefile is an important file. It maynot have a file extension. It enables the BIF: make:all() to compile all the erlang source modules you point it to and transfers all the .beam files to the destination you want.
For example: is i want all the modules in src to be compiled and transfer the beam files into ebin, i enter this into the Emakefile
{"src/*", [debug_info, netload,strict_record_tests,warn_obsolete_guard,{outdir, "ebin"}]}.
In that case i would start the erlang shell with its pwd() pointing in the folder MyProject, to enable the function call make:all() to find the file Emakfile so as to compile all my src files.
Now, suppose you have another OTP app which you want to have as an extra package in your build. If it OTP-like arranged as i have showed you, and not yet built i.e. not yet made, i mean with only its src and its folder ebin are empty or it ebin may be containing a .APP file already. Then you copy this OTP application into your lib folder, so that your application looks like this:
MyProject--/src
/ebin
/lib/some_otp_app-1.0
/include
/priv
/doc
/examples
/test
/Emakefile
then we would change our Emakefile to look like this:
{"src/*", [debug_info, netload,strict_record_tests,warn_obsolete_guard,{outdir, "ebin"}]}.
{"lib/some_otp_app-1.0/src/*", [debug_info, netload,strict_record_tests,warn_obsolete_guard,{outdir, "lib/some_otp_app-1.0/ebin"}]}.
In the folder MyProject, you can put a shell script that will start your project and add all relevant ebin paths to your nodes code path.the sh script may look like this:
#!/bin/bash
erl \
-name my_node#my_domain \
-pa ./ebin ./lib/*/ebin ./include \
-mnesia dump_log_write_threshold 10000 \
-eval "make:all()"
You can save this file as start_project.sh. Hence as you make changes to your source code, even at the time of starting your project, when you run the sh script with your terminal path pointing into the folder: MyProject, you do this:
$pwd
/export/home/your_user_name/MyProject
$sh start_project.sh
This would start your project at the node you entered in the script and would compile all src files which were changed when it was off. Not only this, you can as well call: make:all() in your shell whenever you make cahnges to your src code. then you would call: l(some_module) after making so that the erlang vm reloads the new object code of the compiled module.
So, your entire project will now appear like this:
MyProject--/src
/ebin
/lib/some_otp_app-1.0
/include
/priv
/doc
/examples
/test
/Emakefile
/start_project.sh
So if you substitute the erlang driver for mysql application with this "some_otp_app-1.0", everything will be fine. success!