Comments (6)
That is a really tough one.
I am biased in the Debian way: if you need it, install it via apt-get and it works. A suggestion to completely rework that ("hey, let's just do our own texlive") sounds a little nutty to me.
But then your point about fig, and combining containers is really excellent. I don't understand yet why he path have to be different. Can't we join with binaries from another path that are built from the same vintage (say debian/testing) so that the core dynamic libraries are the same. I may miss a Docker detail here.
Barring that I still our idea of somewhat narrow containers onto which users can add/install new components and then 're-commit'. Once an additions becomes very popular ("grassroots votes", somehow magically aggregated...) we add it. A bit more timid as a proposal.
from rocker.
Cool, I'm totally in favor of the grass-roots approach. We already install a basic tex setup in hadleyverse and I don't see any reason to remove it, since it works for most common uses without any of this linking magic anyway. Currently if a user wanted tex, I'd tell them to use hadleyverse
but I'm just thinking we might document an alternative route that links the tex libraries from a different container. Somehow that feels more docker-esque to me (separate software, separate containers)
a couple quick thoughts:
- Yeah, wouldn't necessarily need us to make the texlive container, one could just tell users to link an existing texlive container.
- I mostly thinking about this from the perspective of a user accessing the container exclusively through RStudio, which means no root permissions (we could add the user to sudoers but we don't at the moment, thinking security-wise for a server product). Such a user cannot apt-get texlive.
apt-get install texlive-full
takes over 30 minutes to run on my desktop, so it's not a convenient fix.- Re joining binaries / paths, you could be right, but I don't see how to do it. I tried creating a container with
apt-get install texlive
, which putspdflatex
in/usr/bin
. I link that binary alone with--volumes-from /usr/bin/pdflatex
. The rstudio container is happy that it seespdflatex
in the path, but it fails to run because the shared libraries that texlive installed aren't linked. (likewise all the other binaries, likelatex
aren't linked yet either). You can't just link a path that already exists on the RStudio container, because the contents of that path that are already on the container get clobbered. Make sense? Can you tellapt-get
to do this kind of more 'isolated' install?
Anyway, so more of a proposal about documenting how to link than about hosting something new.
from rocker.
Maybe we are missing something about how fig or CoreOS combine containers? Seems like it ought to be possible to run binaries from another container, but maybe not.
You can tell dpkg / apt to install (ie "expand the ar archive") somewhere else. But then you own the problem of getting those path covered via $PATH, the dynamic linker etc pp.
texlive-full is overkill. I need to install a fair amount of texlive to build the R packages, and "everything" (unpackaging the chroot, installing everything R needs to build, building, testing, ...) took 14 minutes last week, and my machine is modest. Maybe we "just" need to redefine the problem to not require 1 gb of texlive for everyone? Those who need more esoteric components may have to add them. Or is that too draconian?
from rocker.
whoops, my numbers were out of date. that layer in hadleyverse is now down to 302 MB (and includes a few other things than texlive bits). The texlive layer in r-devel is 1.236 GB, though it installs other things in that layer as well. (note that hadleyverse doesn't inherit this since it doesn't build on r-devel). So anyway, not proposing to tweak the existing containers, where what we have works.
If a user did want some extensive texlive suite though, it might still be reasonable to suggest to them they can just 'plug it in' from another container. Potentially this is useful more generally too? (e.g. someone wants to call python libraries on another container, etc). Mostly I'm trying to wrap my head around if there's a more natural way to combine containers providing different functionality than just stacking on top of the previous container with a "FROM" command.
Good question about CoreOS, I have no idea. My impression was that it was aimed at servers running independent services, I suspect it doesn't support the idea of shared libraries between containers the way a normal linux os would, but that's my idle speculation.
from rocker.
Yep, I also do not know right know if they do more than just combining "services on ports". Naively thinking one "should" be able to union-fs join several containers just how aufs layers get joined inside one.
from rocker.
Okay, don't think this is something we're going to implement, though anyone can already use --volumes-from
with an existing LaTeX container to do this if they like without us doing anything, e.g.
docker run --name tex -v /usr/local/texlive leodido/texlive true
docker run -dP --volumes-from tex \
-e PATH=$PATH:/usr/local/texlive/2014/bin/x86_64-linux/ \
rocker/rstudio
from rocker.
Related Issues (20)
- wiki: best practices for creating dockerfiles HOT 6
- `r-base` (Docker Official Image) is not updated HOT 5
- Migrating from Dockerhub? HOT 3
- Container for RStudio (not server) HOT 1
- MRAN repository snapshots were deleted - Failing jobs because packages can't be found anymore HOT 5
- docker v18 & packages repositories & rocker's images HOT 5
- unable to load shared object
- Update results in deletion of all install package...
- installation testing fails HOT 1
- r: error while loading shared libraries: libR.so: cannot open shared object file: No such file or directory
- Docker image r-base:4.2.1 not reproducible HOT 4
- Installing unstable apt packages? HOT 4
- Local Zotero Integration? HOT 3
- R session terminated HOT 1
- latest r-base breaks install of `curl` package HOT 8
- xz-utils backdoor HOT 4
- Potential high vulnerability in r-base:4.3.1 HOT 3
- Installing packages fails due to broken openssl package in debian testing HOT 2
- Alternative Methods of Extending Images? HOT 5
- update 'latest' version to 4.4.0 RDS security flaw HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rocker.