Rename package from Proj4.jl to Proj.jl

[visr]

See #23 (comment) and comment below.

[c42f]

I'm not sure about capitalization, but other than that 👍

To quote the official word on naming (https://proj4.org/news.html#versioning-and-naming):

• The PROJ.4 project provides the product PROJ, which is now at version 5.0.0.
• The foundational component of PROJ is the library libproj.
• Other PROJ components include the application proj, which provides a command line interface to libproj.
• The PROJ.4 project also distributes the datum-grid package, which at the time of writing is at version 1.6.0.

So maybe just Proj.jl?

[visr]

Ha, yeah, there they name there binary and library by their lowercase filename, but the project they call PROJ. Why do you think it is better not to follow their capitalisation of the project? Not sure why they use uppercase since it doesn't seem to be an acronym.

But yeah, Proj is a bit nicer to type. Doesn't go as well with GEOS and GDAL though ;)

[c42f]

Well, the julia wrapper is just a wrapper for libproj, not the proj command line binary? So it's not the PROJ component per se. LibProj could make sense I suppose.

Having said all that, I'll defer to the current users :-)

[visr]

Yeah I see what you mean, but I believe most wrappers of libprojectname still call their package ProjectName, usually with the same capitalisation as the project uses (as long as it starts with a capital). Like for instance SQLite.jl.

We do distribute the proj binary (and others) as well:
https://github.com/JuliaGeo/Proj4.jl/blob/e72c6f3cabae6facbb3645e4e55c30ad5bbf7bb7/deps/build.jl#L25

And it might make sense to document how to use them like done for GDAL.jl: https://github.com/JuliaGeo/GDAL.jl/#using-the-gdal-and-ogr-utilities

Of course in most serious applications it's better not to shell out, but it can be convenient when converting a command line script.

BTW currently it is LibGEOS.jl, though I actually would prefer to rename it to GEOS.jl.

[yeesian]

BTW currently it is LibGEOS.jl, though I actually would prefer to rename it to GEOS.jl.

The Lib*.jl names were due to me in an earlier period. The modern convention for package names is to move away from them, so I'll be happy for the renaming to happen.

[visr]

Currently renaming without registering a new package does not seem possible yet.
Perhaps we should hold off on renaming until it does.
ref JuliaRegistries/General#2770

[visr]

Actually on further consideration I agree with Chris that Proj.jl is probably a nicer new package name.
It looks nicer, is nicer to type, PROJ is no acronym.
Also there are more packages that do not copy the all caps original naming, such as Metis.jl.
Though feel free to convince me otherwise again if I convinced you before ;)

It's building PROJ 7 right now over at JuliaPackaging/Yggdrasil#966. I'm currently thinking to keep the PROJ_jll compat in this package to max 6, and in the new package 7 and higher. I think that means they cannot be used at the same time though. But I believe that for GDAL builds, we can be flexible and let it pick either.

[c42f]

I still like Proj.jl 👍

I'm not sure you can just rename and keep the UUID, I think that may cause issues in Pkg which expects UUID=>name mapping is well defined? But I think having a new UUID would be fine anyway to go with the new name.

I'd be tempted to rename the repo on github so that issue history is preserved in the main project, then reverse-fork it back to the old name if necessary to maintain the old API during the transition. (Might be worth testing that this actually works though with a dummy project before committing to it!)

[visr]

Hmm interesting. From JuliaRegistries/General#2770 I gathered we have to change the UUID. We could of course do that in this repo, and just add commits that change the API.

Perhaps we can start working in a proj-jl branch in this repo, and merge to master when it is almost ready to be released? And at that point make a proj4-jl branch such that if needed we could still do bugfixes for Proj4.jl?

[visr]

Or perhaps we should just start developing the new API as a second API on master, holding off the breaking changes (removing the old API, changing the UUID) until the end. That may be a bit easier.

https://github.com/JuliaRegistries/General/blob/master/README.md#how-do-i-rename-an-existing-registered-package