Using Python as the basis for a Julia installer

Tooling
1

too heavy and complex a runtime dependency

This means: Designing a method to transparently (and reliably, of course) install Python on supported platforms just so it can then be used to install Julia would be at best clumsy, slow, and error prone.

But, if you already do have a functioning Python installation, then installing Julia is fast and painless. As soon as a new Julia version is released you can do pip install jill, if you don’t yet have jill.py installed, then jill install, to download and install Julia.

2

Sure. Assuming it works on whatever Python installation you happen to have depending on the Python version and all the dependencies being installed already and at a usable version. If that’s the case, great! Otherwise who is going to troubleshoot everyone’s unique, special Python installs? A general, official solution needs to work for everyone. Python is not viable.

Because we all know that using pip is painless and completely reliable!

6 Likes
3

I’ve put a lot of effort into finding how to install Julia for specific projects. I’ve run into this response before regarding jill.py and juliaup: Ignore what I write and what my needs are and what is technically feasible. Push juliaup forcefully and loudly and try to kill every other option. I find it baffling. I kind of understand the goal, but as this response makes clear, this is a counter-productive way to go about it.

I invite anyone interested to read what I actually wrote above. It is short and clear. The responses are bizarre.

Don’t believe the FUD. jill.py has worked perfectly for me in my user environment, in virtual environments, as a command line app, and as a library. And it’s python, so I can and did easily hack it for my needs. Yeah, I know people have problems with Python and pip, and sure, it might not work for you. Python sux, this is not news. But, if you do happen to have a working Python installation (is there an echo in here?) it will take you, if you care to, two seconds to try it… I find it disheartening and embarrassing to have to write this.

  • From the juliaup README:

Note that the Mac and Linux version are considered prerelease, have known bugs and might often break.

FWIW, juliaup worked fine for me on arch linux.

I needed way to automatically install Julia on a system that has a working Python. I feel like writing that all in caps. In a previous conversation I repeated it several times and it never got through. I doubt it will here. jill.py works immediately, via a single python API, for several platforms; Yes, I’m sure there are some that if fails on. And don’t forget how terrible pip is! For juliaup, I would have to implement logic to find out what platform I am on (and find access to platforms to test it), then download or maintain the appropriate installer that installs the juliaup installer. And try to figure out how it works and where components and Julia are installed because its not documented… Oh and a while ago you had to wait for juliaup to be updated when a new Julia version is released. Maybe that’s fixed now. But, I know jill.py doesn’t have this problem.
Don’t misunderstand me, juliaup is great, and all of this will improve and be taken care of. juliaup is the future! But, I need a solution that works today for me.

The rust install pages offer rustup as the best solution for most cases, but mention other ways to install. I wonder why they are so relaxed.

2 Likes
4

This little detail wasn’t very clear until now.

1 Like
5

If jill.py works for you, that’s wonderful. Feel free to use it now and in the future. Your messages seemed to be arguing for a Python-based Julia updater/multiplexer as a viable official solution. The other thread that this was originally part of was explicitly started asking about convergence on an official “serious” solution. All I’m saying is that anything that has a runtime Python dependency is not going to be an official way of installing Julia. That said, no one is going to take jill.py away. It will continue to exist and anyone who wants to can use it. I cannot nor do I want to prevent you or anyone else from using it. If people want to install Julia by transcribing data from clay tablets that’s also fine with me. What I do object to is being told that we need to support that. Similarly, we are not going to officially support installing Julia with an installer that depends on Python.

10 Likes
6

That is the job of Moses.jl maintained by Steve:

steve_upgrades_tablets
steve_upgrades_tablets600×507 88.6 KB

7 Likes
7

Who told you that? What does it have to do with me? What I object to is mischaracterization of my position.

How does anyone interpret that as “being told that we need to support that”? I honestly don’t understand. I guess people are assuming I intended “clumsy, slow, error prone, thus clearly the superior solution.” ? Do I need to say “clumsy, slow, error prone, and therefore not a viable choice for a universal installer. An executable that doesn’t require installing build tools or a runtime is clearly a far superior choice.”

Looks like a joke, right? It’s not. Even that would not be enough. I wrote this in the previous topic:

I agree strongly that the multiplexer feature requires a very fast executable if julia is linked to the julialauncher. But, I think having the option to simply organize and check versions and download and install, rather than launch, is useful. E.g. I want my daily driver to load a custom system image, and maybe I want it to be called julia. As far as I can tell, simply deleting the julia symlink (in linux) to julialauncher is enough to get this.

Does that mean “we need to use Python for the official installer” ?

Maybe this?:

Especially after what has come out in this topic, I am 100% behind the current implementation of juliaup in rust.

No? Not that one? Here is the most ambiguous, or “let’s weight the pros and cons” statement I made:

juliaup does look pretty complicated compared to, say jill.py. And using rust is buying into some complexity and barrier to contributions. It’s worth it if high performance is a requirement, but that’s not the case here [N.B. David pointed out later that it is a requirement for the launcher]. Is the main reason juliaup is written in rust because rustup is? That said, a better choice for a strictly universal installer isn’t obvious to me. Maybe go. I can understand that rust has proven to be better than Julia itself and c++.

I wonder how often Julia is installed in a python-less system. Python has big advantages over rust. It is always installed on linux and macos. It can easily be installed on windows. But, admittedly, that’s (perhaps) not as easy as just going to the windows store. I looked briefly into building a stand-alone Python app for jill with pyinstaller. The resulting executable is 155MB. And the build feels fragile. Startup is a bit slow unless you build an app in a folder. It’s probably difficult at best to make anything close to as lean and fast as juliaup. I don’t see a clear path to a universal installer written in Python.

Is that it? Is that the place where I demanded official support for an installer in Python?

I’m confused, are we on twitter? That must be it. Eagerly awaiting the next widely applauded post slapping down the guy who … :roll_eyes: … can’t stop going on about how much better it would be if we just used Python.

8

I used to advocate for jill (even before it was jill.py) in every Julia release thread. It does work well! I still used it the last time I updated Julia on my Linux desktop.

But now I am a juliaup user on Windows, and I will give it a shot on my Linux computer next time around.

I also don’t know why so many people are pushing for an “official” installation method. It feels a lot like the “this should be in Base” threads. We all seem to agree that 99% of those threads are junk, but somehow people i guess feel differently about an installer?

1 Like
9

The above paragraph makes it look like you are reacting strongly negatively to the statement that an official installation solution should not rely on Python.

In light of your other posts in this thread, which you have just now highlighted, the above paragraph is extremely confusing, and apparently contradictory.

2 Likes
10

I am a strong opposer against any python dependency, no matter if supported or not. But only as a personal opinion and a personal choice. So I instantly reacted on your, was it your first?, post regarding python. I always try to stay on the matter and to avoid any personal assaults, but I also know, that sometimes I fail. So: my apologies for me being part of your bad feelings.

It is a bit inherent of this platform here, or of any discussion platform: Not always when we get an direct answer to our posts, it is meant as that. People just click on the last Reply or start to Reply and during their answer it changes focus and isn’t an direct answer anymore, and so on. Sometimes I wonder myself why is this guy responding to my post and not to OP? Sometimes I feel disrespected when e.g. people just come up with other solutions which doesn’t help to understand or bring any benefit, as a direct answer to my proposal. It’s not always easy to step back.

In this light it sometimes seems that my opinion I have expressed is directly and personally objected and I stand as somebody who advocates for something I don’t. Which is probably not the case and I am the only one who feels that.

But all in all I appreciate all the discussions here even if some go wrong. It’s a nice place to be and to write and an outstanding friendly environment (compared to others).

1 Like
11

I have to say that if Stefan did not write what he had wrote, then I would have posted something similar. I agree with DNF, you citing Stefan’s line “A general, official solution needs to work for everyone. Python is not viable.” and then ranting on how people “Push juliaup forcefully and loudly and try to kill every other option” led me to believe you are discussing the matter of official tools, otherwise, at least to me, the rant would be nonsense: nobody is asking to Jill to be put down, nor anyone would have this kinda of authority (is not infringing nobody rights), the only authority Stefan have is related to choosing the official method of updating Julia, and he made his position clear on this.

I would not go that route, is eerily similar to the meme.

1 Like
13

I’ve split this yet again because we’ve circled back to jill.py — and we don’t seem to be heading in a great direction. I’m going to close this now, but this doesn’t mean that discussions about python-based installers are off limits by any means. We just need to have these conversations without assuming the worst of what others’ write.

5 Likes