GenieFramework / Genie.jl

🧞The highly productive Julia web framework
https://genieframework.com
MIT License
2.27k stars 192 forks source link

Deployment Documentation #174

Closed ChrisRackauckas closed 4 years ago

ChrisRackauckas commented 5 years ago

Genie seems really cool, and I understand how to locally fire up a webserver and make an app. However, I don't understand how to deploy such a thing to Bluehost for example. Maybe this part is obvious to some who does webdev, but I'd be really interested in seeing some documentation on how to get Julia installed on common webservers and getting this running on a real website.

essenciary commented 5 years ago

@ChrisRackauckas thanks for your input! This is coming (I'm actually pretty advanced with the documentation). It's not just the documentation, it's also offering the tools for lifting the heavy load for the users. The idea being to bundle this functionality into some Genie.Deploy module and automate deployments as much as possible.

At this point, there are two main hosting strategies:

  1. Docker containers - this would work on any host supporting Docker deployments. And I have a Dockerfile I use to deploy apps in production, creating a robust environment. Obviously, the instructions from the Dockerfile can be used as a script to set up any Linux VPS, not only Docker containers.

  2. Heroku buildpacks - @milesfrain designed a solution for these: https://github.com/GenieFramework/Genie.jl/issues/163# but it still needs to be incorporated into the docs.


Longer term the objective is to provide a Genie cloud to easily set up and deploy Genie apps with DBs, cache, etc in one command.


If you are familiar with Docker deployments, as an early preview, here is the contents of the Dockerfile which sets up Genie with Nginx (web proxy) and Supervisord (to restart the app in case it crashes).

FROM julia:latest

# dependencies
RUN apt-get update && apt-get install -y supervisor && apt-get install -y net-tools

# nginx
RUN apt-get install -y nginx
RUN service nginx start

# supervisor
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
RUN mkdir /app
COPY . /app
WORKDIR /app
COPY ./Manifest.toml /app/Manifest.toml
COPY ./Project.toml /app/Project.toml
RUN julia -e "using Pkg; pkg\"activate . \"; pkg\"instantiate\"; pkg\"precompile\"; "

# PORTS
EXPOSE 8000
EXPOSE 80

# start app via supervisor
CMD ["/usr/bin/supervisord"]

And here is the supervisord.conf file:

[supervisord]
logfile = /tmp/supervisord.log
logfile_maxbytes = 50MB
logfile_backups=10
loglevel = info
pidfile = /tmp/supervisord.pid
nodaemon = true
minfds = 1024
minprocs = 200
umask = 022
identifier = supervisor
nocleanup = true
childlogdir = /tmp
strip_ansi = false

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[unix_http_server]
file=/tmp/supervisor.sock

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock

[program:genieapp]
directory=/app
user=genie
environment=HOME="/home/genie"
command=/bin/bash -c 'GENIE_ENV=prod julia --color=yes --depwarn=no -q -i -- bootstrap.jl s'
stdout_logfile=/var/log/supervisor/genieapp-stdout.log
stderr_logfile=/var/log/supervisor/genieapp-stderr.log
priority=999
autostart=true
autorestart=unexpected
startsecs=10
startretries=3
exitcodes=0
stopsignal=TERM
stopwaitsecs=10
stopasgroup=false
killasgroup=false
milesfrain commented 5 years ago

Wrote some more detailed documentation in #176 . Direct link @ChrisRackauckas Would you like to test these out to make sure I didn't miss any steps? @essenciary I think we should move https://github.com/milesfrain/GenieOnHeroku to https://github.com/GenieFramework/GenieOnHeroku . Also open to other names, such as GenieOnHerokuExample .

essenciary commented 5 years ago

Thanks so much @milesfrain - I'm merging it into the docs. The mid term objective is to have a Genie.Deployments.Heroku module to automate most of the process -- but until then, the step-by-step guide will be great!

essenciary commented 5 years ago

@milesfrain Sure, happy to move the repo 👍 GenieOnHerokuExample sounds great! I'm not sure what the process is (I only moved mine so I did everything by myself :) ).

milesfrain commented 5 years ago

@essenciary I think the easiest option is for you to create an empty (or with placeholder readme) GenieFramework/GenieOnHerokuExample repo, and I'll make a PR with the files from my repo. Not concerned with losing history in this case.

essenciary commented 5 years ago

@milesfrain Thanks! I'll set up the repo and ping you. I've added a new section for deployment to the docs and linked your tutorial: https://genieframework.github.io/Genie.jl/

Wondering if you have any clue... I've added docker integration to Genie and it works great locally. Then I've tried to use docker deployments with Heroku per https://devcenter.heroku.com/articles/container-registry-and-runtime#getting-started

Everything seems to work well and I managed to push the app on Heroku and I can successfully start it from the Heroku command line and I correctly start the server on the Heroku assigned port. However, when attempting to access the app, Heroku won't serve it.

This is the Dockerfile used by Genie and Heroku:

FROM julia:latest

# user
RUN useradd --create-home --shell /bin/bash genie

# app
RUN mkdir /home/genie/app
COPY . /home/genie/app
WORKDIR /home/genie/app

RUN chown genie:genie -R *

RUN chmod +x bin/repl
RUN chmod +x bin/server
RUN chmod +x bin/serverinteractive

USER genie

RUN julia -e "using Pkg; pkg\"activate . \"; pkg\"instantiate\"; pkg\"precompile\"; "

# ports
EXPOSE 8000
EXPOSE 80

ENV JULIA_DEPOT_PATH "/home/genie/.julia"
ENV GENIE_ENV "dev"

CMD ["bin/server"]

Here is the command running on Heroku:

image

But this is dead: https://safe-bastion-83519.herokuapp.com

essenciary commented 5 years ago

Nevermind, it worked! The dyno was off :-O

milesfrain commented 5 years ago

Very good. I've had strange results in the past when executing commands through their web CLI where it does not behave in the same persistent way as an SSH connection. I was going to suggest posting logs from https://dashboard.heroku.com/apps/safe-bastion-83519/logs which may have also highlighted the issue with dyno state.

essenciary commented 5 years ago

I will split the deployment docs for Heroku into Buildback and Docker. My hope is that with Docker, after Heroku, we'll be able to easily add support for other hosts that use containers, like AWS, Azure, and DigitalOcean, to start with.

Btw, here is the workflow, working now with Genie#master (v0.18.2):

julia> using Genie.Deploy.Docker
julia> Docker.dockerfile() # writes docker file

To run locally:

julia> Docker.build() # builds docker container
julia> Docker.run(mountapp = true) # runs docker container and mounts the app and starts the webserver

Or on Heroku:

shell> heroku container:push web -a $APP_NAME
shell>heroku container:release web -a $APP_NAME
shell> heroku open -a $APP_NAME
milesfrain commented 5 years ago

Yes, I prefer the use of more generic containers to avoid vendor lock-in and also make it easier to test locally with the same container.

I've noticed a slower deployment process, slower startup, and larger image size (~450MB versus ~160MB) for equivalent apps when working with Docker containers versus using the Heroku Julia buildpack. We should investigate these differences further when comparing these deployment strategies and see if we're missing out on any potential optimizations for Docker containers.

essenciary commented 5 years ago

I’ve been doing some research and with the Dockerfile we can easily deploy on all major platforms (including AWS, Azure, and DigitalOcean) using docker machine drivers (it’s the same workflow on any platform supporting drivers).

I’ll run some tests and write some docs. Ideally add extra APIs in Genie.Deploy to support these vs people having to read and run commands in the terminal.

essenciary commented 5 years ago

@milesfrain Sorry for the silly question, but how do you measure the size of the image? I haven't been using Heroku since my Rails days, which were 6-7 years ago, and things have changed a lot since then.

Could it be the creation of the user and its home folder? 300MB for that seems excessive though...

milesfrain commented 5 years ago

It seems that image size is only listed for buildpack deployments, and not custom docker deployments. Here's where the image size is listed for buildpack deployments: https://dashboard.heroku.com/apps/my-app-name/settings

image

For the docker image, I guess you need to check image size on your local system.

> docker images genie
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
genie               latest              e31f40e7187c        9 seconds ago       529MB

This exceeds the base 512 MB limit for most Heroku Dynos.

Interestingly, Genie does start for me on Heroku with the Docker strategy, and appears to be under the RAM limit, but eventually crashes.

2019-09-29T19:01:41.717657+00:00 heroku[web.1]: State changed from crashed to starting
2019-09-29T19:01:53.200923+00:00 heroku[web.1]: Starting process with command `bin/server`
2019-09-29T19:01:56.056219+00:00 app[web.1]: Activating environment at `~/Project.toml`
2019-09-29T19:02:02.890873+00:00 heroku[web.1]: source=web.1 dyno=heroku.147952306.b86fca56-270c-4a83-82fd-5b262c1bc7a4 sample#memory_total=135.02MB sample#memory_rss=134.90MB sample#memory_cache=0.12MB sample#memory_swap=0.00MB sample#memory_pgpgin=30760pages sample#memory_pgpgout=6926pages sample#memory_quota=512.00MB
2019-09-29T19:02:15.302354+00:00 app[web.1]:
2019-09-29T19:02:15.302398+00:00 app[web.1]: _____         _
2019-09-29T19:02:15.302401+00:00 app[web.1]: |   __|___ ___|_|___
2019-09-29T19:02:15.302403+00:00 app[web.1]: |  |  | -_|   | | -_|
2019-09-29T19:02:15.302405+00:00 app[web.1]: |_____|___|_|_|_|___|
2019-09-29T19:02:15.302407+00:00 app[web.1]:
2019-09-29T19:02:18.392961+00:00 app[web.1]: | Web: https://genieframework.com
2019-09-29T19:02:18.393116+00:00 app[web.1]: | GitHub: https://github.com/genieframework/Genie.jl
2019-09-29T19:02:18.39321+00:00 app[web.1]: | Docs: https://genieframework.github.io/Genie.jl
2019-09-29T19:02:18.39327+00:00 app[web.1]: | Gitter: https://gitter.im/essenciary/Genie.jl
2019-09-29T19:02:18.393326+00:00 app[web.1]: | Twitter: https://twitter.com/GenieMVC
2019-09-29T19:02:18.393351+00:00 app[web.1]:
2019-09-29T19:02:18.393435+00:00 app[web.1]: Genie v0.19.0
2019-09-29T19:02:18.393491+00:00 app[web.1]: Active env: DEV
2019-09-29T19:02:18.393494+00:00 app[web.1]:
2019-09-29T19:02:23.020692+00:00 heroku[web.1]: source=web.1 dyno=heroku.147952306.b86fca56-270c-4a83-82fd-5b262c1bc7a4 sample#memory_total=189.81MB sample#memory_rss=189.40MB sample#memory_cache=0.41MB sample#memory_swap=0.00MB sample#memory_pgpgin=48742pages sample#memory_pgpgout=11393pages sample#memory_quota=512.00MB
2019-09-29T19:02:36.985961+00:00 app[web.1]: Web Server starting at http://127.0.0.1:39893
2019-09-29T19:02:42.209221+00:00 heroku[web.1]: source=web.1 dyno=heroku.147952306.b86fca56-270c-4a83-82fd-5b262c1bc7a4 sample#load_avg_1m=0.73
2019-09-29T19:02:42.229706+00:00 heroku[web.1]: source=web.1 dyno=heroku.147952306.b86fca56-270c-4a83-82fd-5b262c1bc7a4 sample#memory_total=208.54MB sample#memory_rss=207.56MB sample#memory_cache=0.97MB sample#memory_swap=0.00MB sample#memory_pgpgin=59609pages sample#memory_pgpgout=17977pages sample#memory_quota=512.00MB
2019-09-29T19:02:53.238931+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2019-09-29T19:02:53.308504+00:00 heroku[web.1]: Stopping process with SIGKILL
2019-09-29T19:02:53.524427+00:00 heroku[web.1]: Process exited with status 137
2019-09-29T19:02:53.573689+00:00 heroku[web.1]: State changed from starting to crashed

Here are the docker steps I followed:

# --- Julia -----
using Genie
Genie.newapp("MyGenieApp")
using Genie.Deploy.Docker
Docker.dockerfile()
Docker.build()

# --- System shell ------
HEROKU_APP_NAME=my-app-name
heroku create $HEROKU_APP_NAME
heroku container:push web -a $HEROKU_APP_NAME
heroku container:release web -a $HEROKU_APP_NAME
heroku logs -tail -a $HEROKU_APP_NAME
essenciary commented 5 years ago

@milesfrain Thanks for trying it out and for the feedback. Works really good for me on a default, free dyno. For ex: https://genie-plots.herokuapp.com/?data=foo,50|bar,30|baz,200|moo,100|bee,-35 This runs really fast after what seems to be initial compilation time -- but it looks like Heroku is turning off the dyno?

2019-09-28T20:13:41.929456+00:00 heroku[web.1]: Idling
2019-09-28T20:13:42.017683+00:00 heroku[web.1]: State changed from up to down
2019-09-28T20:13:42.771058+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2019-09-28T20:13:42.863151+00:00 heroku[web.1]: Process exited with status 143
2019-09-28T20:13:42.785220+00:00 app[web.1]:
2019-09-28T20:13:42.785230+00:00 app[web.1]: signal (15): Terminated
2019-09-28T20:13:42.785232+00:00 app[web.1]: in expression starting at /home/genie/app/genie.jl:10
2019-09-28T20:13:42.785378+00:00 app[web.1]: epoll_pwait at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
2019-09-30T07:48:38.382029+00:00 heroku[web.1]: Unidling
2019-09-30T07:48:38.682948+00:00 heroku[web.1]: State changed from down to starting
2019-09-30T07:48:50.665986+00:00 heroku[web.1]: Starting process with command `bin/server`
2019-09-30T07:49:03.161794+00:00 app[web.1]:
2019-09-30T07:49:03.161818+00:00 app[web.1]: _____         _
2019-09-30T07:49:03.161819+00:00 app[web.1]: |   __|___ ___|_|___
2019-09-30T07:49:03.161820+00:00 app[web.1]: |  |  | -_|   | | -_|
2019-09-30T07:49:03.161821+00:00 app[web.1]: |_____|___|_|_|_|___|
2019-09-30T07:49:03.161822+00:00 app[web.1]:
2019-09-30T07:49:04.953163+00:00 app[web.1]: | Web: https://genieframework.com
2019-09-30T07:49:04.953200+00:00 app[web.1]: | GitHub: https://github.com/genieframework/Genie.jl
2019-09-30T07:49:04.953201+00:00 app[web.1]: | Docs: https://genieframework.github.io/Genie.jl
2019-09-30T07:49:04.953202+00:00 app[web.1]: | Gitter: https://gitter.im/essenciary/Genie.jl
2019-09-30T07:49:04.953203+00:00 app[web.1]: | Twitter: https://twitter.com/GenieMVC
2019-09-30T07:49:04.953204+00:00 app[web.1]:
2019-09-30T07:49:04.953219+00:00 app[web.1]: Genie v0.19.0
2019-09-30T07:49:04.953248+00:00 app[web.1]: Active env: PROD
2019-09-30T07:49:04.953249+00:00 app[web.1]:
2019-09-30T07:49:31.684836+00:00 app[web.1]: Web Server starting at http://0.0.0.0:37946
2019-09-30T07:49:32.875227+00:00 heroku[web.1]: State changed from starting to up
essenciary commented 5 years ago

Yes... so I think it's this:

What is dyno idling?
Apps that have only 1 web dyno will be idled out after a period of inactivity.
The web dyno will be shut down. When a request comes in to an idled app your
web dyno will be automatically spun back up, causing a few second delay for
this first request. Subsequent requests will perform normally.

Apps that have more than 1 web dyno are never idled out. Workers dynos are
never idled out.

In the case of Julia apps, obviously, resuming from idling takes a long time... :-/ 29s in the above example.

I guess a simple way is to use HTTP and make a request every minute or so, from within the app...

Another worth looking into approach is to compile and push a sys image: https://www.youtube.com/watch?v=oxIsFUfaOqU

essenciary commented 5 years ago

@milesfrain Oh, in your case it crashes because you start the app on 127.0.0.1 -- and it needs to be on 0.0.0.0 to bind to the Heroku assigned port (working on the docs for the whole process so it will be clearer soon). Because when using 127.0.0.1 it doesn't bind to the Heroku port, it gets killed in 60s.


On the latest master I switched the default host for dev to 0.0.0.0 (just like prod had). Seems to be the default for other libraries in other languages -- and I expect there will be less friction when deploying.

milesfrain commented 5 years ago

Good catch on the default host. Working for me now on master.

essenciary commented 5 years ago

Awesome - I'm adding some logic to optionally keep the app alive (make a request every Xs in an async task). Can also be used to warm up the app (trigger compilation ;) ).

taqtiqa-mark commented 5 years ago

Hi, Thanks for all your effort you've put into Genie and Searchlight. Apologies if this is not the best thread, but I thought you might be helped by having a look at [jlenv](https://github.com/jlenv/jlenv). This was initially ported by @HiroakiMikami, and then myself. It now lives at https://github.com/jlenv with a curated set of plugins.

It tend to help in deployment situation to mix some sort of version management functionality at the outset.

There are plenty of Rails/rbenv and Django/pyenv instructions and war-stories in the blogoshere, so I won't say more.

Happy to answer any questions.

essenciary commented 5 years ago

@taqtiqa-mark That's pretty cool! Yes, I'm familiar with similar implementations in ruby and python - they're very useful once there are multiple major versions available.

If you want to contribute a jlenv usage doc for Genie, I'd be more than happy to merge it.

taqtiqa-mark commented 5 years ago

I'm still getting my head around how Pkg best fits in. It's quite different to Bundler and Gems. There really doesn't seem to be lots of shell executable files in Julia-world similar to rake, bundle, rspec, gem, etc. etc. Its not yet clear to me if that is due to:

When I've got a better handle on that I'll submit something. Appreciate your thoughts you have on anything jlenv could/should do that would help Genie et. al.

essenciary commented 4 years ago

@taqtiqa-mark If it's any help, my experience building Julia software starting with ideas and architectures borrowed from other languages was that I always ended up with a pure Julia architecture. Julia may look like, say, ruby - but it essentially doesn't have anything in common.

For me the path to success was to always choose the Julia way. Follow the conventions and the strengths of Julia - and let this drive the architecture. Fighting the language leads to awkward and poor performing code.

In this case, my 2 cents are: 1 - maybe shell scripts are not the best idea? It takes a lot of work to write cross-platform code and Julia offers this. You should leverage this by using Julia itself. (Also rvm was a crazy mess of hacks - later replaced by the better rbenv. So the rvm way is probably a bad idea). 2 - can you leverage Pkg and Product.toml -- namely the required compat section which indicates the Julia version compatibility? 3 - could you use something like BinaryBuilder.jl or BinDeps.jl to manage Julia binaries as dependencies of the package? 4 - could you use something like PkgTemplates to allow users to create new projects using a certain Julia version?

More specific, if I'd start something like this today (without knowing anything about it), I'd think in the following lines: a. use Julia b. assume there's a new (latest?) version of Julia available on the system that the user can run c. build the functionality as a package which the user will explicitly install via Pkg and load via using d. work with Pkg and Project.toml - follow a similar logic as Pkg does to load the current package environment. e. in the current Julia session started by the user, check the Julia compat version - download the needed version if necessary (maybe using BinaryBuilder if BinDeps if needed). Then the simplest is to start a new (nested) Julia session, with the desired version (invoking the desired Julia binary), setting the current active project. If this is cumbersome and/or has bad performance, maybe create a custom starter script (bash and wincmd) which starts the desired Julia version with the current project and save this script in the project's folder.

taqtiqa-mark commented 4 years ago

Great feedback. Thanks.

Using your numbering:

  1. Are you suggesting that to change the PATH, and set other shell environment variables that we start a Julia instance, and manipulate the shell from within Julia? Ack: one area the tools in github.com/jlenv need to improve on is providing correct defaults for the env variables Julia consumes.
  2. IIUC: This doesn't address which version of Julia is started when you 'leverage Pkg and Product.toml'. jlenv, chjulia and eventually jlenv chjl should just-work and ensure you have a version of Julia that is compatible with whatever packages are managed by Pkg - that is Julia won't choke on whatever the package configuration files contain.
  3. Possibly. I briefly looked at these. My impression is BinaryBuilder.jl and BinDeps.jl are in states of high flux. When things settle down they may be the way to bootstrap Julia and switch Julia versions as you move around your shell (dev), or run various shell scripts (prod). I think such an approach now is high-risk, low-return: It is likely I don't understand what the added functionality one gets from having Julia manage its (shell) environment. Right now the released scripts work.
  4. Possible, but I'm starting to think we have different use cases in mind. I'll elaborate at the end.

Regarding a)-e): This may be possible. It isn't clear to me what added functionality one gets from this approach.

One benefit I think you could get from this approach, is not limited to this approach - provenance.

I suggested what I thought is a reasonable approach here. I think its fair to say the idea has died. Such provenance assurance around Julia upgrades is likely possible/convenient using a only-Julia approach. But until functionality like signify/minisign are built into Julia, a shell-script approach is the only one feasible right now. Even that would require the Julia-team to make the commitment/change and while it was not rejected, it is fair to infer that the added functionality of 'provenance' is lower on the list of priorities. If it is on the list.

Finally I'll elaborate on the use cases (in my experience).
In some ways they are the antithesis of the behavior in a)-e). 1) Various projects/products/micro-services/etc. etc. are developed in separate folders. They work and don't change much. When they do its critical changes are explicit and never implicit. That is no magic upgrades/installs behind the scenes. Ever. It worked three years ago with version x.y.z. It must work today when I change into that folder and trigger the test suite. chjulia has this as its sweet spot in production environments. Or where devs aren't doing too much across a collection of projects (etc.) that are en-route to prod. 2) Something is in production on a machine that may or may not have Julia available. It must just-work. Now. This is the chef cookbook's sweetspot. Rather than code up Chef recipes/resources (plain old Ruby) for this use case the functionality has been extracted to shell scripts that can be used elsewhere. Of course the Rubyists will say what you said for Julia - just do it all in Ruby it's simpler and better ;) 3) jlenv is some hybrid of 1 and 2. Things aren't so simple for chjulia to be sufficient, but not so complex or slow moving for some Chef/Salt/Ansible etc. to be setup.

Let me know if that clarifies things, and if you think some clarification is required in the announcement thread.

essenciary commented 4 years ago

That sounds great - obviously, you have a lot more experience around this topic. My perspective is simply as a user of rvm and rbenv. With these I would start by picking the ruby version I want for my new project (usually the latest). I'd never use the one that came with the os (cause it's old and changes with os updates). So any new project would use a rbenv provided ruby.

Something like:

So it may be that we think of different use cases. But re your points: 1 - the project would already be set up to use a jlenv Julia. Even if I revisit in 1 year, the project would still be the way it was initially configured and would "magically" use that Julia version. 2 - not sure what the value is to have a Julia app if one doesn't have a Julia runtime on the machine. Sure, one could compile it AOT but a) this doesn't work reliably and scalably yet; b) if it's AOT compiled, then the problem of the Julia version is moot. 3 - I guess it's useful to clearly define the target users. If it's current Julia users, my experience was that they expect things to fit the Julia workflow (ie work with Juno or by launching the Julia Windows app). If it's DevOps, then your assumption is that they will learn to make Julia deployments from scratch, using jlenv. Then yes, one can provide new, specialized workflows, and this is great, but it's long-term long-tail (or at least I'm not aware of an existing Julia user base in DevOps).

===

Update 1: Oh, I think I understand what you mean at #2. Somebody might want to deploy a Julia app from a machine that doesn't have Julia, to a machine which does have it. Sure, yes, that makes sense. Although, why not something like Docker? That would also encapsulate the Julia version.

===

Update 2: I'd say that the question of why not Docker is highly relevant, especially in the context of Kubernetes and the fact one of Julia's major strengths is in distributed computing. So I expect many enterprise deployments will look for this.

maherkhalil07 commented 4 years ago

Hi, can someone help, and explain for me the possibility to get executable binary file from genie?

taqtiqa-mark commented 4 years ago

Hi Adrian (@essenciary ), Thanks for sharing your expectations and workflow. I'll try to sketch out how and where the jlenv org tools might fit.

The jlenv org contains a collection projects addressing the various use cases that give rise to needing to switch between different versions of Julia. These cover a range of use cases:

  1. chjulia: just switch Julia versions: Simple switch and run in prod and dev. Should also set Depot etc. related variables. This would be in installed in a prod only machine.
  2. jlenv & plugins: More elaborate setups and workflows (e.g. jlenv each ...), but not complex or slow moving enough to justify the Chef/Ansible/Salt overhead.
  3. jlenv-cookbook: Manage more complex slow moving setups or where there are some audit requirements such as ChefSpec/InSpec/ServerSpec, or their Salt/Ansible equivalents.

My understanding (could be wrong) of the way Julia works is that Julia consumes a number of environment variables when it starts. These variables are in the scope of these tools - as well as build, install and isolate Julia versions. These variables tell Julia where executable files are, where the package depots are etc., etc. The the jelnv Org scripts will manage those (Ack: at the moment its done badly or not at all). One of those governs which Julia is started when you use $ julia from the shell. IDE launchers will be a use case that needs attention going forward. Other GUI launchers are out of scope (I must clarify this in the docs.)

  1. In many was the need for these tools arise as soon as you've built and installed several versions of Julia:

    I open a Julia REPL

OK. What version of Julia got started when you did that?
Looking ahead; What assurances do you have that it doesn't break when it loads the variables set in your shell or tries to consume MANIFEST, PROJECT.toml, , etc. etc?

  1. The current version of Julia you have running needs to know nothing about other versions. By that I mean Julia is not enhanced by that information (separation of concerns etc.)

    jlenv> ls which gives me a list of all available Julias

$ jlenv versions provides you that list today. The jlenv ls sub-command is reserved for listing environment related data (Julia manages, lists etc. Packages - separation of concerns etc).

  1. The jlenv org tools should have nothing to say with how you do or don't organise your projects. Ideally I'd like to leave you free to do that as you wish.

    downloads the needed Julia version

Think through what is involved in that statement. Doing that from within Julia would mean Julia needs the full suite of sysadmin tools. Example: Verifying signed sources. Julia.Base would need GPG built in. Or your project gets polluted with libraries that have nothing to do with your project, example: GPG, Minisign, etc., etc., etc.

  1. I think psuedo-"magic" would be needed for what you describe ;)

    Pkg would enforce the compat for Julia version ... Does it not?

Correct it does. But what Package Depot does that Julia version use? Ack: At the moment this is where these tools are weakest - they don't yet enforce Depot isolation or Registry preferences.

Hope that helps?

maherkhalil07 commented 4 years ago

Hi, can someone help, and explain for me the possibility to get executable binary file from genie?

taqtiqa-mark commented 4 years ago

@maherkhalil07 , I can't say if there is anything specific to Genie that applies, but perhaps the following thread might help?

https://discourse.julialang.org/t/developing-a-standalone-application-in-julia

essenciary commented 4 years ago

Closing due to lack of activity.