Add Dockerfile #378
Add Dockerfile #378
Conversation
|
Can you squash the commits into one? |
|
Sure - done. Unfortunately cannot retain the original credit doing that, hence I opted to retain originally. |
You can actually, I usually use |
| && git clone https://github.com/aumayr/fava.git \ | ||
| && (cd fava && git log -1) \ | ||
| && make -C fava build-js \ | ||
| && rm -rf fava/fava/static/node_modules \ |
| && python3 -mpip install ./beancount \ | ||
| && git clone https://github.com/aumayr/fava.git \ | ||
| && (cd fava && git log -1) \ | ||
| && make -C fava build-js \ |
There was a problem hiding this comment.
Hm? I can't build it without that:
Exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.5/site-packages/pip/basecommand.py", line 215, in main
status = self.run(options, args)
File "/usr/local/lib/python3.5/site-packages/pip/commands/install.py", line 299, in run
requirement_set.prepare_files(finder)
File "/usr/local/lib/python3.5/site-packages/pip/req/req_set.py", line 370, in prepare_files
ignore_dependencies=self.ignore_dependencies))
File "/usr/local/lib/python3.5/site-packages/pip/req/req_set.py", line 587, in _prepare_file
session=self.session, hashes=hashes)
File "/usr/local/lib/python3.5/site-packages/pip/download.py", line 798, in unpack_url
unpack_file_url(link, location, download_dir, hashes=hashes)
File "/usr/local/lib/python3.5/site-packages/pip/download.py", line 676, in unpack_file_url
shutil.copytree(link_path, location, symlinks=True)
File "/usr/local/lib/python3.5/shutil.py", line 353, in copytree
raise Error(errors)
shutil.Error: [('/root/fava/CHANGES', '/tmp/pip-y5627i91-build/CHANGES', "[Errno 95] Not supported: '/tmp/pip-y5627i91-build/CHANGES'")]
There was a problem hiding this comment.
Oh maybe not, apologies - seems something in the pipeline has started flickering at the most inconvenient time, sigh.
There was a problem hiding this comment.
@aumayr sorry for the delayed turn around on this. I'm having a trouble building recent versions of fava with python3 -mpip install ./fava - I get the above error, my python knowledge is near non-existant so it's highly possible I'm missing something obvious.
It looks like it's attempting to process the CHANGES file for some odd reason? Do pip packages have associated changelogs? Either way, it's not happy with it - any guesses as to why? Irritatingly I'm not able to reproduce this outside of the alpine container - it works fine on my box.
There was a problem hiding this comment.
I was having the same issue here when trying to update yegle/fava docker image. I'm familiar with Python but not very much with Docker, so I'm not sure what happened here.
A quick&dirty solution would be delete the CHANGES file before python3 -mpip install ./fava, but I'm curious to know why it fail here.
There was a problem hiding this comment.
The symlink seems to cause problems with ancient versions of pip, which version are you using?
build-js is part of the default build target, so make -C fava is enough
There was a problem hiding this comment.
The upstream image uses pip 7.1.2, latest seems to be 8.1.2, maybe that's the issue.
re build-js ah, sorry misinterpreted your original comment.
There was a problem hiding this comment.
The upstream image uses pip 7.1.2, latest seems to be 8.1.2, maybe that's the issue.
Hmm the bug I saw should have been fixed in 1.5.... Maybe it's something else then, but maybe try if upgrading pip first fixes it.
There was a problem hiding this comment.
I tried to do python -mpip install -U pip before doing pip install fava, doesn't work either :-(
There was a problem hiding this comment.
pypa/pip#1006 It seems to be fixed long ago, not sure why it resurfaced now.
Additionally switch to the default make task for future proofing and use make clean instead of cleaning up manually.
|
Alright, force pushed CHANGES workaround and suggested changes. |
I'm against this as long as the Dockerfile installs from master. We don't want to distribute that. |
|
@yagebu even if you tag it as unstable? IMO the big advantage to getting it within the official fava repo was so we could do this. Without this people have to maintain their own forks and manually hit build every time fava changes -- there's no way of making it automated through the hub. This means you end up with binary blob images that aren't traced back to dockerfiles, so there's no way to verify the integrity. This was the problem I had with yegle's, I'd have to poke him to hit build on the hub, use a stale HEAD or push to my own hub user and build it there. Would you be happy with this if we had one that tracked the stable releases too? |
|
I'm for maintaining/building two versions:
|
|
Can someone address my concerns that I already posed in #332?:
Of all the ways of distributing an end-user command-line executable, Docker just seems to be the shittiest one. |
|
One should only have to install from master to code or help debugging, which is impossible with the Dockerfile. We had too long gaps between releases so it took too much time for features to land in the released versions, but since 1.0 I plan to something like monthly releases, so this shouldn't be a problem anymore. |
To avoid problems with dependencies there are AFAIK two solutions:
When I do have to install it on machines that are not dev-machines (like my mom's laptop) it is really a PITA to install all dependencies: Get Python 3 onto that machine and then all the dependencies (I don't think Xcode is necessary anymore for building/installing beancount). With Docker this get's way easier: Download Docker, and then just get the Fava image and set Docker to start on startup. That is also the reason I started to wrap Fava in Electron => to make it easier to install and more accessible. I agree that this might not be necessary for an unstable version (as the described use case is just relevant for stable releases), but I guess there are people who just want to try out Fava or something new we develop on master to join the discussion, without the hassle of setting up a proper development environment. |
🎉 |
|
You have some good points. I still think that using Docker is the wrong solution to these problems. PyInstaller offers us a way to build a single executable that users then just have to run, I find that much superior to Docker. If we want to provide a simpler way to install it, we should setup a way to build those, not use Dockerfile as a half-hearted stopgap measure. |
Agreed! Do you have ideas how to automate building them? |
|
(Aside: The absolute dream-setup would be combining PyInstaller with Electron => Fava could be a simple |
Not sure how to best do it. borgbackup/borg offers PyInstaller binaries and uses Vagrant to build them. Alternatively, we could build them on Travis. |
fava-electron does already use PyInstaller ;) And electron-builder does a great job of building an installer, but similar to here, we have to find a good way to build cross-platform... (and make fava-electron just slightly more usable) |
|
(Chime in to offer my opinion regarding docker vs package fava into an app) I started dockerize fava due to various reasons. First, it used to be the case that beancount have new features in tip but not on PyPI, and beancount from tip might be incompatible with fava from PyPI (I forgot if I did encounter an incompatibility though, it was long ago). Second, I need to share fava UI with my wife while I'm the one adding transactions to beancount file, with a NAS at home I can host fava in docker easily. With docker, I edit the bean file on my laptop and then use Dropbox to sync it to my NAS. My wife can then open fava on the NAS to view all my changes in near realtime. Using a tool to package fava into an executable doesn't seem to solve my problem, I still need to find a way to sync the bean file to my wife's laptop. |
How does Docker help with this? I thought you use Dropbox for the syncing, why wouldn't that work with a Fava executable? |
|
@yagebu Syncing a set of files using Dropbox to multiple devices to be used by fava binary is not easy unless every device uses the same root directory, which is impossible with different OS (Windows/macOS). Hosting it on a server in a docker also has the advantage that I can access via my tablet/phone etc. |
I don't quite understand, if you start the binary on a different machine, you can specify a different path to the file.
Ok but than that's quite a different use-case from the one that this Dockerfile here tries to solve. |
|
For me, having fava in Docker allows me to easily add HTTPS and Auth to it, so this is really helpful for a more "complex" setup. |
This adds @yegle's Dockerfile to the contrib directory, preserving all history.
Once merged can you please configure an automated hub build in Dockerhub? I'm unable to do this without contrib rights on the repository oddly. This would mean a new image is built on every commit without someone needing to manually trigger.