What do you think it is worthy to make script or client-side apps that:
At the first glance, it may be useful for beginners and unexperienced users (like students), while (at least) the lang core, its main packages, the atom, and juno itself are under heavy development…
NO!!! the JuliaPro bundle de facto is still unstable, unportable, very rare updated. Its components are outdated, and yet it looks like the refreshing of the some components (like the Atom editor) are intentionally blocked within. I tried to install it on 4 comps… and just in the 2 cases it worked well (from the box)… Of course the idea behind the juliapro bundle is very good… but while its components are quickly changed. the realization i am afraid will be poor…
I think this is a great idea. And have it rebuild the system image for Julia as well. I would be a big fan of this.
From what I understood it was previously a bit complicated because of the way Julia managed the packages (storing them in a remote place rather than close to its installation folder). Maybe this will change with v1.0?
But indeed, this would be a very very useful thing.
No It is not too complicated. But you must do it manually ( of course if you want to be updated), and do it often enough for some reasons. It’s nothing more but a bit irritating when you use Julia solely for your own…and it is hardly appropriate for a classroom with 20 workstations used by unexperienced students.
I seased the project, cos can not get stability even with my very limited set of 3’rd party components.
Have you thought about a docker based solution for this?
Sorry , but it is not matter of the way of deployment it much more due to atom’s, julia’s and juno’s instability. So the basic idea behind was to assemble of most fresh versions of atom, juno, julia on the enduser’s computer. At some cases it would be quite appropriate…The reason for it - most productive way of updating for me is still wiping out all installation taking and setting up the fresh ones step by step.
The promise of using a docker solution for a users computer is that you can control a tight image, preinstall packages, precompile them, get jupyter and dependencies up and running, etc. And if you want to update that image, docker can handle that well to get the latest and greatest.
Since jupyter is probably the easiest for beginners, it would support that without any client installation. Atom/Juno is another issue, but I don’t think downloading and reinstalling Atom is a good idea and dislike the JuliaPro replication of an atom environment.
My experience is that students may find Juno tough to work with at this point, and tend to prefer jupyter. That said, as they get more advanced, users can setup Atom and connect to the docker as a “remote” repl.
I second @jlperla’s suggestion, if not for Docker (which is what I would use, too) then a thin client using whatever your IT prefers. You maintain a single image, users get it on demand, log in to some network drive with their home directory… this is a robust setup.
Then perhaps also consider Jupyter, which is really just a service, nothing to install. It can provide a very smooth experience and may be sufficient for introductory material. I have used it in a classroom setting and it was really hassle-free (except for IT, of course, who had to set it up).
Yes, for sure. The local docker based solution is if you really need users to have local stuff running, but depending on the type of class, that is often unnecessary. Ask your university if they have a jupyterhub installation anywhere, where they could install the Julia kernel. It is your best bet. Alternatively, juliabox is an option in some places but the limitations of the free version will be off putting to users (at least it was in the spring).
Thank you for the advice but i have tryed the other possibilities (and put them into my mind) and I plan to use Julia in an electives as soon as got an opportunity. In my mind Julia and its ecosystem are still not ready for the usage in regular courses.
Go easy with the bold! But I agree. On the current Julia Pro you can’t install the recent DifferentialEquations, meaning it’s basically useless to me and I guess a good proportion of users.
I had hoped it would be a simple solution for say, setting it up for my supervisor to run my packages on windows with atom and everything set up automatically. But its worse than having nothing, because we would have just set it all up manually by now.
hehe yet we come to the starting position (to do everything manually), once more… 
Friends, it seems to me that everybody percieves the current situation quite adequately, whatches upon, and hopes for advances. so there is no reason to pour water in this topic.
For Windows it would be great to use PortableApps template for a Portable Julia distribution.
I actually asked for it more than a year ago:
Well Julia v0.7 makes each package use its own environment, so if JuliaPro fixes a few package versions (on very core packages) then you don’t have to have the rest of your packages all have the same restriction since they can use another version of those dependencies.
as an example, Winpython for python is quite popular, it includes the “starter” data science packages (numpy, pandas…). It is very easy to just copy/paste the winypthon folder on student’s computers and then directly do things using jupyer, spyder, the shell or whatever.
You can also easily modify it to create your own flavour with specific packages installed.
It would definitely be a nice addition / feature for julia.
I agree with @DominiqueMakowski re: Winpython.
For perspective: When I first started learning Python and using Scipy (~2010), there was a PortableApps version of Python with Numpy, Scipy, and Matplotlib. This was incredibly useful for me as it allowed me to avoid Matlab licensing AND have others in my organization run my code. I didn’t have to use Matlab. Others could run my code. Things were good.
In contrast, I’m really enjoying Julia, but what I’m finding is that it’s hard to scale because some people have older machines (i.e. Win7) and there are some issues with that. Some solveable, some not. I’ve found myself translating important bits of my Julia code back to Matlab so others can test, evaluate, etc. with the Julia code that I’ve written. I’m currently looking at PackageCompiler.jl to pre-compile packages for my users. I can mostly avoid Matlab. Others can run sometimes run my code, and sometimes I have to translate functions to Matlab. Life could improve.
I think these are growing pains that will become a thing of the past, but that implies that the present is a bit painful.
Julia should fully support Windows 7. I’ve seen in other threads, that old computers can be an issue, at least for JuliaPro, because they don’t support newer instructions. Even in that case, it’s solvable for Julia (there’s an option for older). As JuliaPro is prebuilt for you, it may not bother with very old computer, understandable, but it should also at least fully support Windows 7 (even XP, while no longer officially supported, would work to a large degree I believe).
I find it curious that some people find it easier to obtain a working setup for running Matlab on Windows (both of which are closed source, cost money, and come with usage restrictions, even if Windows is installed “for free” on most OEM computers) than, say, Julia on Ubuntu, which takes about half an hour to setup from scratch with a reasonable internet connection, requiring skills far less advanced than programming.