# Best way to wrap a Julia package for use by those that can't code?
**URL:** https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680
**Category:** Tooling
**Created:** [June 10, 2021, 2:16pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680 "2021-06-10T14:16:15Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)
#### Post date: [June 10, 2021, 2:16pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/1 "2021-06-10T14:16:15Z")
# Goal
My goal is to gather input from the user with as little barrier to entry as possible. Then process it with Julia, and finally collect tables, graphs, and text into a report (preferably PDF). The user inputs I need are a few file locations and floating point numbers. The user should have a place to conveniently enter these inputs and then just click “run” to generate the report from their data. I don’t want them to have to interact with the package functions directly.
# Background
I know Julia and some very basic LaTeX, but that is about it. I have no experience with GUIs or the Web Stack, but I am willing to learn any new technology that would help. I am looking for some direction on what to focus on learning to achieve my goal above.
# Current State
### Processing
I have the package itself in place already with functions for transforming, plotting, and printing the data.
### Pre-Processing
I have included a directory called “run” in the repository containing the package with a “runthis.jl” and some auxiliary files. The “runthis.jl” file is the only file the user needs to change and run. It defines the input data I need with commented instructions next to each line. Then it `include`s all the auxiliary files in the “run” directory which in turn call the package functions with the correct syntax in the correct order.
### Post-Processing
The post-processing functions are also called by the auxiliary files inside the supplemental “run” directory. I am using PrettyTables.jl and Plots.jl to print output to the REPL and save figures to disk. Is Weave.jl still the best choice to get these into a PDF instead? I haven’t had a chance to try it out yet. (I don’t intend to show any code in the report.)
### Issues
The current set-up is working okay, but there must be a way to simplify it further.
1. The user still has to dive into the repository and sift through code to enter their inputs.
2. The user usually copies the “run” directory from the repository and stores it next to their data before changing the inputs. The “runthis.jl” file has `using MyPackage` at the top, so this works fine. Except then I don’t know how to maintain version control between the two. If I update the package after the user has copied the “run” directory, then “runthis.jl” will probably break, and the user won’t know why.
I’d appreciate any tips. Thanks.
---
### Author:  [@Jeff\_Emanuel](https://discourse.julialang.org/u/Jeff_Emanuel)
#### Post date: [June 10, 2021, 2:34pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/2 "2021-06-10T14:34:30Z")
> I have no experience with GUIs or the Web Stack, but I am willing to learn any new technology that would help.
Indeed, these were invented to solve problems like yours. If you are willing to learn, then I suggest learning how to stand up a web service that runs your julia code. The service should serve an HTML page that includes GUI elements that allow the user to set the parameters. The page calls back to the service, and the service can respond with the .pdf if it is useful to the user or write it to file if it is only useful to you.
If you implement this as a web service with a GUI HTML page, then the user doesn’t even need to install julia.
Start with HTTP.jl.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [June 10, 2021, 2:40pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/3 "2021-06-10T14:40:53Z")
Can your package be provided as a web server? Then you could build a very simple “upload” site for the data, run the package in the server in the background, and report the result. I have done that with a few packages.
Otherwise, I think a good alternative would be to provide a double-clickable julia script that launches a very simple GUI in which the user would provide the data and click “Run”. I would also be interested in advice on how to provide that. This kind of thing, maybe: [https://github.com/GenieFramework/Stipple.jl](https://github.com/GenieFramework/Stipple.jl)
---
### Author:  [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)
#### Post date: [June 10, 2021, 2:53pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/4 "2021-06-10T14:53:45Z")
Yeah, I think I will need to focus on something local for now since the data files can be large.
I think the biggest annoyance right now (besides #2 Version Control) is having to copy the file locations into the code as a String. Do any simple GUI file selectors already exist?
---
### Author:  [@lungben](https://discourse.julialang.org/u/lungben)
#### Post date: [June 10, 2021, 3:11pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/5 "2021-06-10T15:11:24Z")
As an alternative to a web server, you could also provide a Pluto notebook. The user can interact with it using PlutoUI elements, including File Picker.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [June 10, 2021, 3:17pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/6 "2021-06-10T15:17:48Z")
I thought about that. Is it easy to create an “installer” (for windows users, in particular) that creates a double-clickable file in the desktop that will launch that Pluto notebook?
---
### Author:  [@lungben](https://discourse.julialang.org/u/lungben)
#### Post date: [June 10, 2021, 3:37pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/7 "2021-06-10T15:37:48Z")
You could create a Windows link file with the Target
`C:\Users\xxx\AppData\Local\Programs\Julia-1.6.1\bin\julia.exe -e "using Pluto; Pluto.run(notebook=\"test.jl\")"`
However, for installing Pluto and creating this link there is no ready-to-use solution yet.
---
### Author:  [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)
#### Post date: [June 10, 2021, 3:49pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/8 "2021-06-10T15:49:11Z")
> [@Jeff\_Emanuel](#):
>
> The service should serve an HTML page that includes GUI elements that allow the user to set the parameters. The page calls back to the service, and the service can respond with the .pdf if it is useful to the user or write it to file if it is only useful to you.
> [@Jeff\_Emanuel](#):
>
> Start with HTTP.jl.
Am I able to keep all this traffic on a shared local server rather than through the web with HTTP.jl?
---
### Author:  [@cchderrick](https://discourse.julialang.org/u/cchderrick)
#### Post date: [June 10, 2021, 4:15pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/9 "2021-06-10T16:15:00Z")
I would guess the easiest path is keep everything on local machine, via localhost, like jupyter. Sharing on LAN just require some open ports? And it definitely will need some network configuration to share it to the whole world. You can run a local server on `http://localhost` using HTTP.jl.
---
### Author:  [@Jeff\_Emanuel](https://discourse.julialang.org/u/Jeff_Emanuel)
#### Post date: [June 10, 2021, 7:18pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/10 "2021-06-10T19:18:37Z")
Yes, as @cchderrick mentions, your service can open a port that is not exposed outside the local server, or outside the local network.
---
### Author:  [@StevenSiew](https://discourse.julialang.org/u/StevenSiew)
#### Post date: [June 10, 2021, 10:42pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/11 "2021-06-10T22:42:00Z")
Nathan, I got a couple of Questions to ask
1. What platform should the “solution” run on?
Windows? Mac? Linux?
2. How many users need to use the “solution”? 1? 10? 100? 1000?
3. How big are the files that the users provide? 1kb? 1Mb? 1 Gb?
4. Where should the users run the “solution”? On their desktop? Do you have to install it manually on their desktop?
5. How often do you need to “update” your code? Daily? Weekly? Monthly? Yearly? Never?
---
### Author:  [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)
#### Post date: [June 11, 2021, 2:34pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/12 "2021-06-11T14:34:07Z")
Currently,
1. Windows OS
2. 6 users
3. Between 10Mb and 1Gb total input size
4. Running on personal desktops. All users have access to a shared network drive which is mapped to their desktops. The package is stored and accessed from there.
5. I push updates to the shared version about monthly. I am still actively developing the features.
Improvements based on the current requirements is obviously the first priority, but cross-platform and easily sharable solutions would be good to know too.
---
### Author:  [@Jeff\_Emanuel](https://discourse.julialang.org/u/Jeff_Emanuel)
#### Post date: [June 11, 2021, 4:23pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/13 "2021-06-11T16:23:22Z")
With so few users that access the code through a shared drive, perhaps most expedient until you need a broader scope would be a simple gui in GTK.
---
### Author:  [@Jeff\_Emanuel](https://discourse.julialang.org/u/Jeff_Emanuel)
#### Post date: [June 11, 2021, 4:43pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/14 "2021-06-11T16:43:11Z")
> [@Nathan\_Boyer](#):
>
> I will need to focus on something local for now since the data files can be larg
Perhaps longer term you could deploy the proposed web service in the cloud and the users can upload their data to cloud storage (like AWS S3) and point your service to their storage.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [June 11, 2021, 5:32pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/15 "2021-06-11T17:32:16Z")
> [@Nathan\_Boyer](#):
>
> 6 users
For a small group like that I would go the easy way: Install the Julia binaries from the site, double-click it (which will open the REPL), and just show them one step-by-step example with copy/paste input parameters. It can be simple as:
```julia
] add YourPackage
```
copy/paste this to run it:
```julia
using YourPackage
run_yourfunction(
inputfile1="mdata.dat",
parameter1=10, parameter2=20,
output="myoutput.dat"
)
```
With that approach telling them to `up YourPackage` whenever you want is also quite easy.
---
### Author:  [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)
#### Post date: [June 11, 2021, 6:14pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/16 "2021-06-11T18:14:16Z")
> [@Jeff\_Emanuel](#):
>
> perhaps most expedient until you need a broader scope would be a simple gui in GTK
I’ll look into it.
> [@lmiq](#):
>
> For a small group like that I would go the easy way
That would avoid having to manage the “run” folder, which would be nice. I would just have to handle the different input options and analysis types with multiple dispatch. One concern would be that I now have to store documentation separately from the inputs, so it wouldn’t be as obvious if I change how you have to input something. Another would be more frequent typos, especially as the number of parameters change.
> [@lungben](#):
>
> As an alternative to a web server, you could also provide a Pluto notebook. The user can interact with it using PlutoUI elements, including File Picker.
Maybe Pluto is the right move after all as long as I can keep the file management simple. It would provide GUI elements and Markdown documentation in place.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [June 11, 2021, 6:30pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/17 "2021-06-11T18:30:59Z")
> [@Nathan\_Boyer](#):
>
> I would just have to handle the different input options and analysis types with multiple dispatch.
Or with keyword parameters, which might be easier, which can handle all default parameters, if these do not change every time (avoiding, then, some typos).
---
### Author:  [@lungben](https://discourse.julialang.org/u/lungben)
#### Post date: [June 11, 2021, 6:54pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/18 "2021-06-11T18:54:17Z")
> [@Nathan\_Boyer](#):
>
> Maybe Pluto is the right move after all as long as I can keep the file management simple. It would provide GUI elements and Markdown documentation in place.
The current Pluto main contains the new automatic package management (see [🎁 Package management · fonsp/Pluto.jl Wiki · GitHub](https://github.com/fonsp/Pluto.jl/wiki/%F0%9F%8E%81-Package-management)), which makes managing of package dependencies much easier. If you need non-published packages, you can set up a local Pkg registry.
For file transfer you can use the PluoUI File Picker for smaller files (up to a few MB). For larger files you can use remote storages or network folders shared between the users and the Pluto server.
One step further, you could set up a [GitHub - JuliaPluto/PlutoSliderServer.jl: Web server to run just the `@bind` parts of a Pluto.jl notebook](https://github.com/JuliaPluto/PlutoSliderServer.jl) so that the users cannot manipulate the notebooks themselves anymore (and therefore not break them), but just interact with the UI elements.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [June 11, 2021, 7:02pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/19 "2021-06-11T19:02:15Z")
> [@lungben](#):
>
> One step further, you could set up a [GitHub - JuliaPluto/PlutoSliderServer.jl: Web server to run just the @bind parts of a Pluto.jl notebook](https://github.com/JuliaPluto/PlutoSliderServer.jl) so that the users cannot manipulate the notebooks themselves anymore (and therefore not break them), but just interact with the UI elements.
Cool! I was just thinking if that was possible!
---
### Author:  [@lungben](https://discourse.julialang.org/u/lungben)
#### Post date: [June 11, 2021, 7:03pm UTC](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680/20 "2021-06-11T19:03:00Z")
It should be, but I have not tried it myself yet.
[Next page](https://discourse.julialang.org/t/best-way-to-wrap-a-julia-package-for-use-by-those-that-cant-code/62680.md?page=2)