I probably will too.
Somehow disappointing, I was very enthusiatic about the possibility to compile code to an *.exe (within Windows). Fortunately, there are other (less sophisticated) scripting languages which allow me to create exe’s until Julia is ready.
I probably will too.
PackageCompilerX allows you to do this: https://juliacomputing.github.io/PackageCompilerX.jl/dev/apps.html
@vinod_kc first thanks for this question. Can you confirm whether the latest version of Package Compiler solves your problem? And if so, what has changed since October 2019?
Hi, interested too…
I remember that beside using a setup.exe files to install Win softs…
I did use sometimes MSI files instead for Windows OS installs.
Would building an MSI file instead of an exe be a way to build Win executable files ?
I’m no exe/msi builder specalist enough to answer that !
*more info on the MSI format here :
my 1 cent !
editing : another possible tool maybe…
I think (maybe wrong) we are lacking something that help new developers used to have build tools, usually embedded in the IDE, to produce a full sharable software bundle or “the current best we can do option”. All the suggestions I see here are relatively to dependent on how julia internal works (load mechanism, packaging, precompile images, etc). If we compare this to a one build button click alternative we can see my point.
I was so excited about Julia so far. But when I read how difficult it will be to distribute programs to Windows users, I get disillusioned again. There are already such massive problems with Python that Python can’t be used most of the time, because you can’t create an executable with it. At least not as easy as in Rust for example.
Here are some possible reasons for problems:
- Users do not have admin rights
- If you want to run it on a server, sometimes there is no internet available
- Or there is internet for non-admins and a user with admin rights can’t get to the internet.
- If working in Citrix environments, the installations “disappear” because they are not in the user folders that are synchronized, but in some other folders that are not synchronized.
- Sites from which packages should be fetched online are blocked by IT
- Programs that require admin rights to install or run often have to be “listed” before you are allowed to use them.
It is so much easier when you can create a ready-made program that works without admin rights.
While I mostly agree with you, one minor quibble is that Julia can be really nice to use on a linux server since the “install” is just having a folder somewhere. No Admin required.
Same for Windows - no admin rights required to install Julia.
That lack of Internet connection is a valid problem. I wonder if it’s possible to set up a local package server?
I more or less agree with you. Do you have a graphical user interface for the package? Windows users want to double-click something to start with. One alternative is to install julia (I think the Julia installation is simple enough).
If the user is completely averse to command-line, given that Julia is installed, one could in principle provide two commands, one that installs the package and one that launches a GUI.
If the user is expected to actually use Julia writing some code, the greatest problem I see is that Windows user usually have no idea of where the files are, and what is the path to their scripts, for example. I experience that a lot by sharing an executable (Fortran) that is used by many people, but is expected to be run from the command prompt. The users double-click in it, and “nothing happens”, and it is hard to explain to them that they must put the executable in the path and run it from the directory where their input files are.
With that in mind, if one can instruct the user to 1) Install Julia. 2) run a single command (like launching a Pluto notebook), and 3) working with the notebook/application that is then opened, it seems easier than sharing a general command-line executable.
I don’t see having to to install Julia as a major problem (again, if we can provide a installer that adds it to the path that is even easier), and that is why, for me, the fact that the program is distributed as a standalone executable or not is not the major issue.
The problem is having one’s application as “double-clickable” in some sense, and that dependencies on opening data files or scripts have to be handled by following the standard searching and clicking in a folder browser. These two requirements, of the application, depend on writing at least a simple GUI.
Thus, if Julia is installed by a installer, and our application can be installed by a “double-click” that launches Julia and runs
Pkg.add..., with that creating another “double-clickable” icon, distribution would be easy. Most of the distributions to non-programmers could be done like that, without actually requiring an executable. Probably an effort to provide guidelines in these directions (and see what is missing for that to be easy) is worthwhile.
My main business is BI based on MS Sql Server and other Microsoft stuff. Python is often used in this area but I wanted to test Julia.
SQL Server tools (SSMS, Azure Data Studio) also can be used to enter and update data in databased, but there are limits, for example with multi-line content in cells. So one of my goals is to create a simple GUI which also could be used to enter data in a more flexible way. Often I use Access via Odbc. And then my idea was: why not use Julia also to create some kind of GUI? But now I am not sure. Maybe it is better to Julia for math, Maschine learning and so on, with Jupyter Notebooks and just scripts, and not to try to build a GUI with Julia, which need to be delivered as application or as web based solution, but to use other languages to program a GUI. There was also the idea to use Jupyter Notebooks to connect with databases, and it looks like the Jupyter-Lab can be extended with some SQL support. But I did not get this work. And all this depends so much on Python.
BTW, my experience using Julia in VSC was and is very good. Easy to install, the Julia extension works great and I can use Notebooks also in VSC with Julia kernel. But I don’t think that I could extend VSC (or Azure Data studio) for my goals to create a GUI for CRUD operations. And even if this would be possible then TypeScript needs to be used.
I have a package that makes this more seamless. FloatingTableView.jl.
I think so.
browse accepts all the same keyword arguments as
showtable. But I have no idea how editing tables works with that.
Hola, soy nuevo también en Julia. En algunos sitios dice que es un lenguaje compilado, pero como no crea un ejecutable, pues creo mas bien que es como un lenguaje interpretado (porque necesita tener instalado el compilador de Julia para funcionar). En todo caso, Python es un lenguaje interpretado pero si se pueden crear ejecutables. En un tiempo se uso algo como pi2exe, pero se quedó atrasado y después usé cx_freeze y funciona bien. Yo acudo a Julia por curiosidad, pero todo lo que programo ahora va encaminado a windows y también necesito el .exe
Bienvenido a la comunidad @MIGUEL_HIDALGO_INIGU. Es cierto que Julia es compilado pero “justo a tiempo” o en otras palabras, se compila justo antes de ejecutar el código, sin producir un ejecutable. En este momento creo que la manera más popular de crear un ejecutable es a través de PackageCompiler.jl pero diría que no es una solución ideal por ahora (si la mayoría de tus programas son para compartir con gente que no sabe programar). Si Julia es una buena solución para tí o no depende totalmente de qué clase de problemas necesitas resolver.
A post was split to a new topic: Non-english discussion section?
well, try to explain that to colleagues for whose excel is a rocket science in constrained corporate environment.
distributing exe is way safer for number of reasons when level of computer competence varies wildly