Thanks everyone for your swift and detailed replies, happy to be here!
Before I reply to each one individually I want to justify putting packages into an organization. From my perspective there are numerous advantages in having the repos in the organization:
- Inspires more trust.
- Increases the pool of people that are likely to review a PR.
- Newcomers have a specific collection to search for packages.
- Invites more contributions by non-members (why? because the repo is detached from a single person’s name).
- It is much easier to find! Because once you find one package from JuliaGeo, you immediately see that it is from JuliaGeo, and thus you click and you go to the org’s page.
I urge you all to consider putting your packages in an organization (probably JuliaGeo, since JuliaAtmosOcean is actually just 1 package which could join JuliaGeo). At the moment there is a lot of scattered material, e.g. GeoStats, ClimateTools, ClimateMaps, NCDatasets all have different owners (and in fact, I’ve only became aware of GeoStats and ClimateMaps after your posts, which would not be the case if they were part of JuliaGeo).
Transferring is quite trivial thanks to GitHub, this is how I’ve done it for people joining JuliaDynamics or JuliaMusic:
- Invite the owner of the repo to the org (and all important contributors).
- The owner transfers the repo to the org via the settings.
- Create a Team on the org with owner level access to the transferred repo. Make original owner (and all important contributors) part of this team.
The last step ensures that the person that initially owned the repo still maintains all privilliges while not getting full privileges over the entire org. JuliaClimate is an alternative if JuliaGeo is not fitting, but one should be transparent about their scopes then.
@juliohm, GeoStats.jl will certainly be useful, so I’ll add it to the list of “packages to study”. For the beginner issues you cite, probably the missing values and the Unitful.jl are the ones I could tackle at the moment. Could you please describe them in more detail on the GitHub issue page, so that they are more approachable from a beginner’s view? I’ll also keep an eye on the unified interface for data.
Cool, I can help with that for sure. This is what we did with Agents.jl lately when we ported it to JuliaDynamics. I think after porting to version 2.0 we have effectively reduced the complexity of the package by half (which is amazing!!!).
I couldn’t agree more. Separating plotting functionality from actually scientific computing is extremely important. Not only it speeds up everything, it reduces file sizes but it also makes it much easier to run stuff on the cluster. Perhaps you can open up an issue outlying in detail what should be done, and I have a look? (Btw we also separated plotting from Agents.jl when we ported it to JuliaDynamics)
I also agree fully with that and it (massively) helps newcomers. As Stefan Karpinski once said “there should be one package that does that one thing, and it should be the best package”. (Same goes for the 2 NC reader packages imho).
@visr thanks for pointing to this comment, so I can see some different scopes there. What you propose is definitely useful, i.e. reducing code by adding inter-dependencies. But it should also be made clearer in the docs/readmes which package to use for what reason (i.e. what are their actual target goals).
Although you have a point, I am not so sure I would be as concerned as you about this. In the end of the day, if there is enough material so that a new organization is necessary, one can just transfer the repos with 2 clicks. At the moment maybe it is worth considering JuliaClimate as an org, but of course I am a newcomer and i shouldn’t be the one judging that.
In my eyes an organization is more about thematic connection between packages, and ease of finding them, and not so much for functionality connection.
@joa-quim thank you for the suggestion of GMT.jl, seems that it is useful to easily plot an ncdataset. But on the other hand yet one more way to load netCDF data just makes things more complicated for me. I’ll stick with NCDatasets.jl for now.
@fabiangans Cool, thanks! Thankfully I will be working with a small dataset (~1gb) for the start of my project, but as I move along I’ll keep this in mind!
I also like your approach of how one “maps” their analysis onto the datasets. It will certainly come in handy for me.
Please do, the number is 408!