Why don’t we do it in the open-source way? Allow anyone who has tested/used any packages that work for him post their names into an open list.
As somebody who just decided to start using Julia, I have to say that it is incredibly frustrating to hit ] add SomePackage, then find out it can’t be installed.
This is exactly how to stop people taking up the language.
Unfortunately Neonlights tells true fakts. Actually im trying to run Seismic.jl and GMT.jl and both dont work. I would really like to know, if its just anythink that i’m missing or if voth packages dont work in version 1.0.
Lukyly i have worked with Julia for a while, so i wont give up on the language… For new users, this could be the other way round
Please realize that you are complaining about the work of volunteers who are doing this largely for free and largely for the benefit of others.
If you want the situation to improve, join us in the
#upgradathon channel on Slack and help us make a difference. Otherwise please be patient.
Providing feedback is part of contributing. And is not like they are not willing to do work and are just complaining. They are assessing the current status and asking about an alternative which is to provide a platform to contribute. @Keno already have the results from previous runs, so even if it is a Google spreadsheet with OK and not OK that would work and people can test the latest release locally and crowdsource that information.
Many developers have partial knowledge of the ecosystem since we already had to verify the status of the dependencies for our projects, but new users might lack even such.
@quinnj put together a spreadsheet from the PkgEval run earlier this week: I don’t think it makes too much sense to try to hand-curate it, but hopefully that gives some idea at least: https://docs.google.com/spreadsheets/d/1Q_FKJuYYiro1UjHjm1gHdGh47Vo1VMVm9LwjdGR9UBM/edit#gid=40571623
Thanks! Would be nice to have the release tested to know if one should expect a change in the status.
Cool! I’m excited to see how this changes with the next update now that the Images.jl and WebIO.jl stacks are working on 1.0.
Happy to keep updating it as @keno shares new PkgEval results; it’s pretty easy to update.
Why do you say that GMT.jl doesn’t work? Tests clearly show that it does (despite what’s in Keno’s link) and I’m currently working on it right now adding more modules, so good time to submit issues.
How is that information generated? I see that it says that GMT fails but it doesn’t
Master passes but probably new version is not yet tagged. Keno is testing released packages.
Tagged version passed as well.
You’re asking your users to manually install a binary dependency. PkgEval doesn’t read READMEs . It runs Pkg.add in a fairly minimal Linux environment (very few things work, no compiler, only basic utils installed) and then tries to run the tests.
Right, but couldn’ it use the info of Travis-CI instead?
I can make a script that just takes the status from the Travis CI API… I ran it a couple weeks back for a paper on various languages using R, but can make the script in Julia available.
The ideal solution would be to try using BinaryBuilder and BinaryProvider to install this dependency for your users when they do a
Pkg.add. I know it’s a major pain, but those new tools aim to make it easier. I highly recommend Elliot’s talk from this year’s JuliaCon as an introduction.
It seems fair to evaluate based upon what a user would experience with a
No, the point of PkgEval is to evaluate the experience of a user who just does Pkg.add.
I haven’t looked at it carefully yet but from a quick look I got the impression that windows binaries are built with gcc, right? That’s a hard pill for me to swallow as I’m the guy who builds gmt (not the wrapper) for windows an I’m quite keen to keep doing it with VS.
youre right: i managed to run GMT now. In fact it was because i tryed to use a 4.xx version istead the 5.xx version of GMT, so it was my failure. But to answer your Question: I did say GMT didn’t work because it didn’t worked for me at that time and i was not able to find out if that was because of Julia Version problems or because i am doing something wrong (wich was so). And as you pointed out… theres no List to trust right now.
My Seismic.jl problem still exists.
What i was NOT willing to say was any proven fact about a package running or not. Sorry if my post was creating that apperance