The people working on a particular project make the decisions about that project. In the case of Julia (GitHub - JuliaLang/julia: The Julia Programming Language, that is), that’s the core developers; a very loosely defined group of people that anyone could join, in principle. They don’t make decision for any other projects, like other packages in the ecosystem, or third-party installers that someone decides to make.
And other people have decided to make alternative installers, like the JuliaWin that was recommended before. As I pointed out at the time, that doesn’t always seem to work out very well. But you can certainly make an installer that fits your needs, or the needs of your colleagues or customers.
Nobody in particular, really. Or, maybe the groups described in the Julia Governance document I linked earlier. Or the consensus of the many people driving particular aspects of the Julia ecosystem forwards, loosely organized here, at JuliaCon, on Slack, and other venues. The community is much more diffuse and consensus-driven than you seem to be comfortable with, or willing to accept.
Not really. The way it works is how Matt described how juliaup got adopted: Someone just made juliaup, and then, after it got a lot of traction, someone made a PR to add it to the website, and at this point there’s a broad consensus that juliaup is the supported way to install Julia.
I would agree, so it’s probably better to figure out who to talk to about the existing installer(s) and fix those. But ultimately, you can still start from scratch and make your own. If it gets adoption, it can then replace the existing installer.
Sorry, but I don’t think we really have what you’re looking for, and there’s nobody who’s exactly in charge of giving you the “one graphical installer” that you desire. It has to be made by someone with a business need or some other intrinsic motivation to create it. And it may be a need of the core developers, since they obviously want people to be able to install Julia. But you or some other user wanting a graphical installer with particular features does little to bring it into existence.
Maybe Julia will develop in ways that will make it much more accessible to a wider audience of less-technical users. Removing unnecessary technical hurdles is always a laudable goal. But let’s not kid ourselves. It’s a programming language. It caters to developers. Knowledge of version schemes, IDEs, REPLs, and, for that matter, Git/GitHub and the command line are pretty much table stakes.
Unfortunately, this multi-thread discussion with you seems to be going in endless circles. Quite honestly, I’m not sure if Julia is really a good fit for you. I’m not saying that to dismiss your concerns, many of which are absolutely valid. At some point (can’t find the link anymore) you listed the technical requirements for your project. Based on those requirements, I would not have recommended Julia as the best solution. Don’t get me wrong, Julia is probably my favorite language, but there’s a great many things where I wouldn’t reach for Julia as the best tool for the job. Of course, stretching a language to solving technical problems that it’s not quite ready for can be a lot of fun (with a certain pain-resistance), and is the only way to really push the language forward. But then on top of that you seem to have a lot of very firmly held opinions about how software should be developed that just don’t mesh with the realities of the Julia ecosystem. That’s not a recipe for happiness. I hope I’m wrong!
