Hi!
Is there a function in Julia similar to file.choose() in R or tkinter.askopenfilename() in python that allows to browse through the filesystem and returns a path string? I searched a bit, but did not come across anything like that for Julia.
Thanks!
Alex
Hi Alex!
A similar question was posted here How do you open a "Choose File" prompt from Julia? - #3 by Iulian.Cioarca
Only 1 year old, perhaps it helps
@Jeff_Emanuel beat me to it! (Another post albeit) 
Kind regards
Thank you both, @Jeff_Emanuel and @Ahmed_Salih ! However, while installing Gtk lots of useful packages, such as DataFrames and ScientificTypes and MLJ, have been seriously downgraded and I need the functionality of the newer versions. So, I was forced to uninstall Gtk. Is there any other alternative to Gtk?
Here are the specs of my machine, if there is anything to see in them that helps…
Maybe https://github.com/barche/QML.jl works better for you.
As noted in another thread on the same topic, Gtk.open_dialog("...some prompt...") works, at the cost of pulling in a Gtk dependency.
Another possibility, as discussed in Pluto.jl#350, would be to wrap this library (or similar) in a JLL (binary package) and then write a Julia wrapper: https://github.com/mlabbe/nativefiledialog … or perhaps even to re-implement/port it to native Julia with ccall.
Thanks @stevengj ! I can see the logic…but I am a simple language user. And if @fonsp says that he cannot do it, imagine a beginner that I am. 
https://github.com/fonsp/Pluto.jl/issues/350#issuecomment-687776235
I think that this sort of functionality would make everybody’s life much easier and would be cool to have around as an inbuilt utility.
Thanks though! If I find time (and that is a big IF) I can spend some time on that…
Fyi, all the latest versions of those packages could be installed in Win10 Julia 1.7.0-beta4 with no worries:
DataFrames v1.2.2
Gtk v1.1.9
MLJ v0.16.9
ScientificTypes v2.3.2
Packages dependencies are blackboxes to me but the Gtk.open_dialog() feature seems to be very useful, even essential, for more interactive code. So quite interested in your problem.
I wrote this monstrosity a few years ago for my use on Windows. It shells out to PowerShell to create a file dialog then parses the results. Needed a tweak to get the uigetfile function working again (I’m using PS7 compared to PS5 when I wrote it) the others would probably need tweaks too. Obviously ugly and could be done better (I’m a much better Julia programmer now) but does get the job done (on Windows). I wonder how hard it’d be to whip up a package, atleast for a specific OS.
I haven’t used this code in a few years as I mostly work in notebooks now and so my filepaths are stored in a cell for convenience and reproducibility of the notebook.
edit to add that this doesn’t “open” the file it just returns the path as a string or an array of strings if you select multiple files. Makes it a tad easier to get a variable with your filepath in the REPL is all.
Thanks for letting me know, @rafael.guerra ! I will try installing 1.7 and will give you the heads up about anything new I learn about this.
For the time being, am using and combining inline utilities such as pwd() and split(read(`ls`, String), "\n") to get back directories’ contents.
There shouldn’t be a need to download 1.7 for this. That’s overkill (plus, 1.7 is still in beta). Most likely the downgrades are nothing to worry about.
Good for windows users! But, no luck for us, mac users…no PowerShell over here…
@pdeffebach Among other packages, for DataFrames it makes a difference. The downgrade is to a 0.X.X version, whereas the 1.X.X versions have been a major release. You are probably right that it could be an overkill, but I am ready to pay the price.
That is indeed a big downgrade. But the resolver shouldn’t downgrade past a breaking version. I also don’t think the problem is 1.6 vs 1.7. I’m on 1.6 and can make the following environment just fine
(jl_q6koNG) pkg> st
Status `/private/var/folders/hw/wyk0x5g92cb9w8xy3v7mm9lm0000gn/T/jl_q6koNG/Project.toml`
[a93c6f00] DataFrames v1.2.2
[4c0ca9eb] Gtk v1.1.9
[add582a8] MLJ v0.16.9
[321657f4] ScientificTypes v2.3.2
Thanks for the testing @pdeffebach ! What you say and show sounds reasonable. But am wondering whether there is something wrong with my resolver that needs to be corrected. Do you think you could give me a hint as to where to start searching for this potential issue?
ps: The downgrading happened in two other new installations, too. A side note is that I have all stable Julia releases since 1.3 on my machine. Do you think that would be a possible source of the problem?
Can you post the output of import Pkg; Pkg.status()?
@pdeffebach Earlier, I installed a slightly newer version than the one I have had the problem with; so from Julia 1.6.1 to Julia 1.6.3 and I managed to install Gtk & DataFrames with no packages getting downgraded! So, these have been good news!
After installing a new Julia, I guess there is point into doing import Pkg; Pkg.status(), since there not many packages installed right now.
PS: An indirectly relevant question is the following: Is it the right strategy, when one does a fresh Julia installation, to do the following (that I also do to keep all the packages of the earlier version?): E.g. copy the .julia/environments/v1.5 folder to .julia/environments/v1.6. Or is there another safer way to install all packages to a newer version? Thanks!
You can use osascript to do the same thing in macOS:
osascript -l JavaScript -e 'a=Application.currentApplication();a.includeStandardAdditions=true;a.chooseFile({withPrompt:"Please select a file to process:"}).toString()'
Yes that’s perfectly fine. It seems to me that your problem is that you dump all your packages into the default environment, which then leads to a situation where there’s a third package other than Gtk and Dataframes which shares a dependency with them leading to some incompatibility. As others have shown, Gtk and DataFrames can happily coexist on the latest version on a new environment, so you should probably just create a fresh environment for what you’re trying to do, which will be a lot easier than trying to wrap some external library
@nilshg That is what I am thinking of doing from now on. Thank you all for the responses and, more importantly, the patience!