On Saturday, October 17, 2015 at 3:29:32 AM UTC, Tony Kelman wrote: > > Why many packages don't support Windows? It's par for the course in > open-source development, unfortunately. I gave a talk on this at JuliaCon > in June where I discussed some of the challenges in making things work on > Windows and how to go about fixing them, see > https://www.youtube.com/watch?v=mbG-rqDCNqs - if you find packages you > use that aren't currently testing on Windows but could be, I encourage you > to submit pull requests adding appveyor.yml files and suggesting the > authors enable Windows CI testing. > > Julia makes it easy to wrap C and Fortran libraries so people do exactly > that quite often, >
You mean e.g. with Python. I can think of one exception (or not?): Java. At least in the beginning, that was one of it's point: "write-once-run-anywhere" WORA (that assumed JVMs in web browsers..). Strictly speaking, you can go out of the JVM, with JNI and have all the cross-platform issues.. I understand WORA didn't quite work as intended, but aren't most Java projects self-contained, only using Java code (or languages that compile to) and Java's frameworks? Is it possible to replicate their (relative) success? If you use only Julia code, you are portable already and codes just work.. > but building most of those C and Fortran libraries on Windows is > nontrivial. Witness Anaconda, which exists to make binary installation of > libraries in the Python ecosystem possible so you don't need a compiler on > the user's machine at install time. In Julia we tend to focus on individual > platform-specific tools, like WinRPM.jl for a large number of packages on > Windows and Homebrew.jl on Mac. > For non-Julia code, is Conda.jl the solution? > > > On Friday, October 16, 2015 at 3:56:44 PM UTC-7, Joel wrote: >> >> Thanks for the information; food for thought. >> >> Out of curiosity, do you know why this is the case, by the way? >> >> Den fredag 16 oktober 2015 kl. 21:00:12 UTC+1 skrev Tony Kelman: >>> >>> Quite a few Julia packages are written in a way that assumes you're on >>> Linux or Mac with build tools installed. Not all, and we're gradually >>> fixing cases where packages can be made more portable. Best thing to do for >>> now would be to submit a pull request adding a note to the readme that the >>> package does not currently work on Windows, to save future users a bit of >>> confusion. >> >>
