Should this really be a Pkg function? Isn't this useful for other modules as well? Maybe dirname(::Module)?

@fredrikekre, it doesn't work for arbitrary modules, since it only makes sense for modules that come from a standard Pkg directory structure. (Modules don't even have to come from files!)

True, but the answer to the question from a package will be loaded has nothing to do with the implementation of the package manager. Forcing a dependency on Pkg for something that it just directly asks Base code loading about seems unfortunate?

Sure, it's easy to move this to base. What should the function be called, and should it be exported?

How about abspath(::Module)?

That feels like a little bit of a pun but I kind of like it.

How about abspath(::Module)?

I would expect this to return /path/to/package/src/Package.jl and not /path/to/package/. Maybe returning /path/to/package/src/Package.jl is more useful anyway?

Maybe returning /path/to/package/src/Package.jl is more useful anyway?

Yes I believe so, especially because AFAIK there's nothing that says a package has to have a particular directory structure, so it may be the case for example that a module is defined in /path/to/package/Package.jl with no src directory. So for full generality, it seems like the full path to the file in which the module was defined would be best. That's my $0.02. 🙂

Maybe every module should just know what source file it was defined in with nothing being the answer if it was defined in the REPL or some other non-source-file location?

Yes I believe so, especially because AFAIK there's nothing that says a package has to have a particular directory structure,

Yes, there is, look for "src" in loading.jl.

Maybe every module should just know what source file it was defined in with nothing being the answer if it was defined in the REPL or some other non-source-file location?

Implicit const __FILE__ = @__FILE__ in each module?

Yes, there is, look for "src" in loading.jl.

Oh. 😐 Alright then. Well, I still think returning the file is useful. 😛

Changed to abspath and made to return the file.

CI is looking good.

Marking as triage as otherwise there is no non-deprecated way of getting this info without mucking around in Base internals.

@StefanKarpinski and/or @KristofferC will have to decide this one.

I'm a little uneasy about overloading abspath for this but I suppose it seems ok. I'm also not super into the multiargument version since this seems like a somewhat more useful definition:

abspath(m, paths...) = joinpath(dirname(abspath(m)), paths...)

@StefanKarpinski, I removed the paths... args.

I'm a little uneasy about overloading abspath for this but I suppose it seems ok

It does feel like a bit of a pun. Packages are loaded based on LOAD_PATH; perhaps to get the path from which a package is loaded, one should use loadpath(::Module)?

which(module)?

Maybe where(m) instead?

I don't particularly like where, both because we already use that as a (non-reserved) keyword and I don't find it very descriptive.

Having path somewhere in the name of the function seems worthwhile, as it signifies that what you're asking for and getting is a path.

My problem with loadpath is that it sounds like a verb: "load the path". I dunno, maybe pathof? But I don't have strong feelings about the spelling here and am happy to change the PR to whatever people want.

A nice thing about pathof is that I can imagine it being extended to other things, e.g. file descriptors, IOStreams, Cmds, etcetera. (But we could also use abspath for this.)

I think pathto reads a little nicer than pathof, since in prose you'd say "the path to X," but I'm also fine with abspath.

I don't like pathto because this is not the path to a module—whatever that is; it's the path of the file in which the module was defined, which pathof seems to pithily describe. Moreover, it's reminiscent of nameof which is a similar kind of reflection function.

Isn't this a new feature, and thus can be designed after 1.0?

@JeffBezanson, it is and it isn't — the problem is that an old feature, Pkg.dir, was deprecated in 0.7 and there is no documented replacement. So if we wait until 1.1 for this we will end up with a bunch of packages relying on undocumented Base internals.

Yes, but it makes things like documentation deployment and coverage submission much easier in CI, since currently scripts have to call Pkg.dir. With this they would be able to do julia -e 'using Package; include(joinpath(pathof(Package), ...); dostuff'.

edit: 3 second ninja'd by Steven.

Changed to pathof.

Yes, but it makes things like documentation deployment and coverage submission much easier in CI, since currently scripts have to call Pkg.dir. With this they would be able to do julia -e 'using Package; include(joinpath(pathof(Package), ...); dostuff'.

For this particular case you shouldn't need Pkg.dir-like functionality though, see e.g. https://github.com/JuliaDiff/ForwardDiff.jl/blob/d7ebc3d2eca3c1c4b10815cff8900bee9a600761/.travis.yml#L18

CI is green and we're waiting on a couple of other things before tagging RC1, and with any luck that will be tagged before this week's triage. So can we make a decision here in short order?

Well that's a decision if I've ever seen one 😛