Don’t understand the fuss about Python on Windows. WinPython works perfectly and can either be installed in portable or integrated way.
Right, can’t install pyjulia but I can’t neither with the Conda version.
2 Likes
“Works perfectly, but just known to fail on the first thing you try”. Yes, that’s exactly why I would say it’s not a great experience.
Where did I say it was the first thing I tried? Can use PyPlot with no problems for example.
No it’s the first thing I tried. That’s how “you” works. It works so well that you were able to, off the top of your head with no prompting, point out the thing I just tried and failed with. Such a prophecy of “you’re going to try it but give up when you cannot figure out how to make X work” is not the marker of working perfectly in my book 
Not sure I follow “you”. Are you referring to this error?
(base) C:\j>python
Python 3.9.7 (default, Sep 16 2021, 16:59:28) [MSC v.1916 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import julia
>>>
>>> julia.install()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\programs\miniconda3\lib\site-packages\julia\tools.py", line 111, in install
proc = subprocess.Popen(install_cmd, **kwargs)
File "C:\programs\miniconda3\lib\subprocess.py", line 951, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "C:\programs\miniconda3\lib\subprocess.py", line 1420, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified
FileNotFoundError seems to me that may perfectly be due to a bug in the program.
I’ve moved these posts to a new thread because whether Python works well enough on Windows or not isn’t really relevant to using it to manage Julia versions. Even if it worked perfectly, it’s too heavy and complex a runtime dependency for that use case.
10 Likes
11 posts were split to a new topic: Using Python as the basis for a Julia installer
I think that python with Conda on windows works perfectly fine - or at least as well as conda ever works (i.e., it requires a complete reinstall and exorcism every 6 months). WSL is useful but it is limited and often low-performance and things like GPUs, file accses, etc. are a problem. I think its main purpose was to build out infrasture/tooling/etc. to support Azure - but I could be wrong. Regardless, saying python doesn’t work on windows and everyone just uses WSL is just not true.
With all of that said, it doesn’t change anything. Requiring a functioning python dependency for ANYTHING related to Julia is a nightmare. Keeping a python installation with pip/conda working for python alone is hard enough - regardless of which operating system is used!
9 Likes
Every time people lament how difficult using Python on Windows (in my circle mainly for scientific computing) is, I am wondering if they have given the conda-approach a try.
Granted, 5+ years ago it was more difficult and fragile, but nowadays on a new Windows machine I install mambaforge (small distribution, faster than conda, conda-forge package repo). Installation is a simple download + doubleclick, does not need the windows store or admin rights, puts itself on my path (iirc), and I can easily create separate environments per project and easily update the base Python version. I haven’t had to reinstall the whole conda installation in a long time (~2 years until a job change, and now nearly one year and counting)
As a side note, as an experienced Pythonista and Julia beginner, it seems to me to be somewhat fashionable in this community to dump on Python, not always justified in my opinion, and that is one thing that make it less likely for me to engage here. I’d rather people argue on the basis of Julia’s many strengths than on other langs’ perceived weaknesses.
4 Likes
The conda distribution has a well-known problem on Windows right now where it gives an incompatible SciPy binary first reported in August. You need to do export CONDA_DLL_SEARCH_MODIFICATION_ENABLE=1 in the Windows shell to fix it, or as a conda-forge maintainer recommended, try mini-forge. That’s not the kind of issue that a basic installation should have.
Look, maybe some of you like running your own Arch Linux and finding what configuration of window managers gives you a solution that works for a month, but some of us just run away when we hit any installation issue. The conda solution has known issues with the packages people would want to use here, the first comment of this thread says we should instead use WinPython but oh, that fails with pyjulia. Literally even Microsoft recommends using WSL, did they miss something you all know?
Some package installations have never gotten everything to work on Windows. Can you please tell me why FENICS gives you a Linux-based Docker to install instead of doing it natively with your easy solutions in Windows? (Note: they used to give you a VM to download). Could you give them the quick fix? Sage had so many problems running on Windows that it wasn’t until v8 (2017) that it gave an installer that wasn’t just a VirtualBox to run a pre-installed Sage on Linux. Is that our new definition of “works perfectly”?
In the Julia ecosystem, Linux distro installations have a similar problem where some packages do not work because they build with an incompatible LLVM. We call that broken and post warning messages everywhere telling people that those installers are not supported and should never be used. Only the generic binaries on julialang.org should be used. The same exact kinds of issues show up with these Python distributions yet instead I’m supposed to agree that they “work perfectly”?
So how about this, let’s make it concrete. What is the Python distribution that has a GUI point-and-click installation where I can expect all of the major packages (numpy, scipy, tensorflow, pytorch, jax, graphx, etc.) to just work without having any other external compilers or anything installed, and has the appropriate downstream testing so that any update to Python that causes an issue with one of these packages on Windows is appropriately blocked until fixed? That’s the level of support I get on Windows with Julia, MATLAB, Mathematica, Maple, etc. We have PkgEval do this for us, with Windows buildbots and downstream tests, BinaryBuilder environments and servers vendering CUDA installations so things can work out of the box. That’s not a high bar, it’s just what’s expected in 2022.
If installing Gridap.jl on Windows required installing a Docker to work, people would say that the Julia distribution and packaging ecosystem has failed. We should not define the same behavior as “working perfectly” for Python just because we’re used to it.
5 Likes
That specific advice seems to narrowly apply to web applications because they never deploy on windows . Microsoft has a Linux cloud and WSL/etc is a sandbox for developing and testing cloud software to deploy on azure, containers, etc. I don’t think WSL is intended for high performance local production use quite yet.
So yes, if you are developing web apps to deploy to the cloud use WSL. If you are running other stuff, the packages are in conda, and want gpus locally, etc then don’t. Conditional on having a working conda installation and not accidentally breaking it, everything works fine on windows.
There are constant stream of problems in conda. If you think that is bad, try to come up with cross platform setup instructions for pytorch that always work for GPUs.
There are many great things about the python ecosystem (especially pytorch, pytorch lightning, pandas, and friends) and even the language due to its insane level of dynamic flexibility. But with manifests, binary builder, etc Julia is in a different class entirely for reproducibility since 1.3. It is an enormous advantage.
So I agree with the spirit of what you are saying about python’s package managers and their fragility being difficult to support (even in python only setups). I just think you are misreading the WSL advice.
2 Likes
As I showed in my comment the failure was with Conda and I added tat it fails with WinPython too and the error is a “File not found” which does not look to come from a broken Python.
I primarily use Julia on Windows, and am not a Python user. I was toying with trying out the matplotlib backend hoping it would be more like using matlab figures, which I like. I understand that would require installing Python. The discussion above discourages me from trying it.
Any advice?
Automated Matplotlib installation
If you set up PyCall to use the Conda.jl package to install a private (not in the system PATH ) Julia Python distribution (via Miniconda), then PyPlot will automatically install Matplotlib as needed.
If you are installing PyCall and PyPlot for the first time, just do ENV["PYTHON"]="" before running Pkg.add("PyPlot") .