Rename package

[carlobaldassi]

In light of the recent auto-require changes, this package should probably be renamed to OptionsMod, so that using OptionsMod is sufficient to load it.

Either that, or the module name should be changed to Options and the type to something else (Opts?).

[StefanKarpinski]

Or we should figure out some way of allowing a module and a type exported by that module to share the same name peacefully. cc: @JeffBezanson.

[timholy]

If that's feasible, it would be nice. Since this problem with Options became clear, it's affected my naming of things in other packages .

[johnmyleswhite]

+1 for allowing modules and types to share names.

[timholy]

Unless there are objections, I'm going to go ahead and change the name of the type to Opts, and make the module name Options. The usage of the @options macro means that users don't really even typically see the type name.

[HarlanH]

Well, end users don't see the type name, but package/code authors usually write something like opts::Options in the formal parameters, right?

[timholy]

Definitely.

[tshort]

+1 on the name change.

[sbos]

@timholy sounds good

[JeffBezanson]

We can address this as part of a general redesign of how modules are located. See issue JuliaLang/julia#2375. If type Options.Options is going to exist, we need a really robust way to know what we're talking about in different contexts. For example, using Options; import Options.x should probably still work, in which case we need a special lookup rule for import and using (it is already slightly special).
An even better example is the case using SomeWildPackage; using Options, where, unbeknownst to you, SomeWildPackage actually exports its own thing called Options.

[timholy]

OK, I'll sit tight and see what unfolds.

[s2maki]

If this is going to get renamed, I would hope for a better name than OptionsMod or Opts. Neither of these (nor Options) is particularly descriptive. I would quote point four from the documentation:

Err on the side of clarity, even if clarity seems long-winded to you.

[kmsquire]

@s2maki, this package was written before keyword arguments existed in Julia, and is still around for compatibility purposes for older packages. It should be deprecated at some point, and probably won't be renamed.

For newer code (or old code that you want to upgrade), check out http://docs.julialang.org/en/release-0.3/manual/functions/#keyword-arguments.

[kmsquire]

(Closing this. If it's still relevant for some reason, please reopen.)

[carlobaldassi]

This package is still used by ArgParse, see carlobaldassi/ArgParse.jl#13.
There's also a new issue with the name because of the recent require deprecation. The switch to import (see https://github.com/carlobaldassi/ArgParse.jl/pull/14/files) gives a warning because the module name is different from the file name. So now it is not clear how to load this package without getting a warning.

[kmsquire]

Thanks for the clarification, @carlobaldassi.

[StefanKarpinski]

@carlobaldassi, how much work would it be to make ArgParse not use Options? Or are you keeping it as is for compatibility with 0.2?

[carlobaldassi]

Compatibility with 0.2 is not a priority of mine, just a consequence of the fact that I did not have the need to bump the version until now.
Removing the Options dependency from ArgParse is something which I could work on, but I'm not sure when (I don't have much time lately, unfortunately). It would also be breaking, although not dramatically so. Anyway, if the general consensus is to retire Options as a package I could certainly work on that at some point.

[StefanKarpinski]

Yes, there's no hurry, but I think that once 0.4 is out, deprecating all use of 0.2 would make sense.

[carlobaldassi]

Update: I have now updated ArgParse to avoid the dependency on this package.
The name should still be changed IMO (it still has some nice functionality which is not 100% covered by keyword arguments - and I vote for OptionsMod for simplicity), but at least this is not preventing precompilation of other packages now.

[StefanKarpinski]

What functionality does it have that keywords don't? I'd really like to get rid of Options.jl, tbh...

[tkelman]

No recent versions of anything still use this. It should probably just be deprecated and moved to JuliaArchive. @carlobaldassi I sent you an invite to that org.

[tkelman]

Renaming packages after they've been registered is kind of a pain. I moved this to JuliaArchive and we can think about officially deprecating it in METADATA.