- repro builds to use fixed uid=1000 inside the container
- in case the file permissions leak into the binaries, they are still reproducible
- chown 1000:1000 fresh_clone
- repro builds to create fresh_clone dir outside git clone
- otherwise the local dev build would still interact with the fresh_clone dir
- due to e.g. recursive "find -exec touch",
- and even the "docker build" cmd itself would try to stat/read it
- see https://github.com/docker/for-linux/issues/380
- and "rm -rf fresh_clone" needs sudo if the host uid is not 1000
- this way the local dev build does not need sudo
to recap:
- local dev builds use the host userid inside the container, directly operate on the project dir
- does not need sudo
- repro builds create a fresh git clone, chown it to 1000, and use userid=1000 inside the container
- if the host userid is 1000, does not need sudo
- otherwise, needs sudo
closes https://github.com/spesmilo/electrum/issues/8261
maybe fixes https://github.com/spesmilo/electrum/issues/7640
Looks like by default pip is ignoring the locally available setuptools and wheel,
and downloading the latest ones from the internet at build time...
https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/?highlight=no-build-isolation#disabling-build-isolationhttps://stackoverflow.com/a/62889268
> When making build requirements available, pip does so in an isolated environment. That is, pip does not install those requirements into the user’s site-packages, but rather installs them in a temporary directory which it adds to the user’s sys.path for the duration of the build. This ensures that build requirements are handled independently of the user’s runtime environment. For example, a project that needs a recent version of setuptools to build can still be installed, even if the user has an older version installed (and without silently replacing that version).
>
> In certain cases, projects (or redistributors) may have workflows that explicitly manage the build environment. For such workflows, build isolation can be problematic. If this is the case, pip provides a --no-build-isolation flag to disable build isolation. Users supplying this flag are responsible for ensuring the build environment is managed appropriately (including ensuring that all required build dependencies are installed).
If only it were that easy!
If we add the "--no-build-isolation" flag, it becomes our responsibility to install *all* build time deps,
hence we now have "requirements-build-makepackages.txt".
This diff should not change what is matched by gitignore
(e.g. `build/` matches `contrib/build-wine/build/`).
I am experimenting with reusing gitignore as dockerignore which uses
slightly different semantics.
related: https://github.com/spesmilo/electrum/pull/7431#discussion_r677541811
Load DLLs from inner 'electrum' dir instead of '.dlls'.
To make it consistent with where we expect libsecp256k1 (.dll/.so) be.
(note that while in case of libsecp we specifically already search the main dir,
without this change, other DLLs such as libusb or libzbar would not be found there)
Python 3.8 changed where DLLs are searched for.
see https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew
This potentially affect our binaries when we start shipping python 3.8+, however that is not being addressed here. This commit simply addresses the usecase of running from source, on Windows, using python 3.8.
On older Python, a user could build/obtain DLLs and place them anywhere on the system %PATH%, however this no longer works with py3.8, as %PATH% is no longer checked.
With py3.8, instead, we now check if there is a folder named '.dlls' in the top-level project directory, and if so, register that as an additional search path.
A user who wants to run Electrum from source on Windows using python 3.8 or later, with their custom DLLs, should manually create the '.dlls' folder and put their DLLs there. If they also want to switch between e.g. python 3.7 and 3.8, they should also include '.dlls' in the system %PATH%.
When using Electrum, interesting DLLs include at least libsecp256k1.dll, libusb-1.0.dll, libzbar-0.dll.
so we don't need pyrcc5, which is not deterministic,
and so we don't need the submodule for the icons
based on electrumsv/electrumsv@bf8802c2eaf0bf75565b5423a95bcb85ec7eb781
Benefits of this rewrite include:
- support of disconnecting / reconnecting a device without having
to close the wallet, even in a different USB socket
- support of multiple keepkey / trezor devices, both during wallet
creation and general use
- wallet is watching-only dynamically according to whether the
associated device is currently plugged in or not
MEIPASS is PythonInstaller specific and won't work for py2app
modified: lib/util.py
modified: .gitignore
modified: lib/util.py
modified: setup-release.py