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

Add Dockerfile #20

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

islamelnabarawy
Copy link

This PR adds a Dockerfile that allows you to run the downloader without having to install nodejs or add a global package. It defines a docker volume at /downloads that you can mount to where you want your wallpapers to be downloaded.

To build the docker image, clone the repo and then execute the following command inside the cloned repo:

docker build -t interfacelift/downloader --build-arg uid=1000 --build-arg gid=1000 .

The uid and gid arguments are optional, but I recommend using them so your wallpapers are created using your own user and group instead of root.

After building the image, you can run the downloader using the following command:

docker run --rm -v $(pwd):/downloads interfacelift/downloader

This will download 1 image in the current directory. If you want to download more than one image, you can pass the number to the run command. This will download 10 images:

docker run --rm -v $(pwd):/downloads interfacelift/downloader 10

I couldn't figure out a way to change the resolution and still keep the nice exec form for ENTRYPOINT, since it doesn't do argument substitution. If I think of a way around that, I will add it and update. Right now, the default resolution is 1920x1080, and I'm afraid you have to modify and build the Dockerfile if you need a different resolution.

I hope this is helpful for others too.

@stevenbenner
Copy link
Owner

This is a great idea! I can certainly see the benefit of using the tool via a docker container. It would make it so people don't need to install the whole node.js toolchain in their host environment.

I'm not very well versed in docker configuration, but looking at the docks it does seem that CMD can be used as a list of default parameters which can be overridden at run time. So would moving the arguments to CMD make it so you can set the resolution (and perhaps other options) when you docker run?

@islamelnabarawy
Copy link
Author

@stevenbenner Sorry it took me a long time to respond, somehow I missed the notification about your comment.

The way I thought to design this at the time was to use a combination of ENTRYPOINT and CMD such that if you supply a command when you run the image, it gets appended to the ENTRYPOINT argument list, allowing you to specify the number of images to download instead of the default CMD value of 1. It seemed like the most convenient option for me at the time, since changing the resolution is such an infrequent thing compared to deciding how many images to download.

I think you can use the --entrypoint switch for the docker run command to completely override the ENTRYPOINT directive, which I believe would be a decent workaround if you need to get a different resolution occasionally without rebuilding the image.

The only other way I could think of to do this would be to specify everything as a CMD directive, but that would mean having to specify the entire command every time you want to get a different number of images or change the resolution. You can do that if you would prefer it that way than having to modify the Dockerfile to change the resolution. I haven't tested it, but I think it should work.

I just pushed an update to the Dockerfile that uses the ADD command instead of doing a git clone during the build process. It's faster and avoids cloning the repo twice or hard-coding the URL inside the file.

@billylaing
Copy link

billylaing commented Sep 20, 2018

Howdy! @stevenbenner you still interested in doing this? Happy to help.

@stevenbenner
Copy link
Owner

stevenbenner commented Oct 13, 2018

Yeah, this still seems like a good idea to me.

I'm just not knowledgeable enough to be able to evaluate the config, test it, publish it, and maintain it. My ideal (based on my limited understanding) would be that users could pass arguments to docker at run time and it would work the same as the script. And it seems like docker hub is the most popular way to publish dockerfiles, so that is probably where it would need to end up eventually.

Also, I'm wondering if the docker script should be in a different repo? Since it would ideally be something that can be published on its own.

I'll let you all tell me the right way to do it.

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

Successfully merging this pull request may close these issues.

3 participants