Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add pathof(::Module) #28310

Merged
merged 10 commits into from
Jul 31, 2018
Merged

add pathof(::Module) #28310

merged 10 commits into from
Jul 31, 2018

Conversation

stevengj
Copy link
Member

@stevengj stevengj commented Jul 27, 2018

Closes #27592. abspath(FooModule) returns the path of FooModule.jl. The package directory can be obtained from abspath(FooModule, "..", "..").

@stevengj stevengj added the packages Package management and loading label Jul 27, 2018
@fredrikekre
Copy link
Member

fredrikekre commented Jul 27, 2018

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

@stevengj
Copy link
Member Author

@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!)

@KristofferC
Copy link
Member

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?

@stevengj
Copy link
Member Author

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

@stevengj
Copy link
Member Author

stevengj commented Jul 27, 2018

How about abspath(::Module)?

@ararslan
Copy link
Member

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

@fredrikekre
Copy link
Member

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?

@ararslan
Copy link
Member

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. 🙂

@StefanKarpinski
Copy link
Member

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?

@KristofferC
Copy link
Member

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.

@iamed2
Copy link
Contributor

iamed2 commented Jul 27, 2018

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?

@ararslan
Copy link
Member

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

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

@stevengj stevengj changed the title add Pkg.dir(::Module) add abspath(::Module) Jul 27, 2018
@stevengj
Copy link
Member Author

Changed to abspath and made to return the file.

@stevengj
Copy link
Member Author

CI is looking good.

@stevengj stevengj added the triage This should be discussed on a triage call label Jul 29, 2018
@stevengj
Copy link
Member Author

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

@ararslan ararslan mentioned this pull request Jul 30, 2018
13 tasks
@JeffBezanson
Copy link
Member

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

@StefanKarpinski
Copy link
Member

StefanKarpinski commented Jul 30, 2018

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...)

@stevengj
Copy link
Member Author

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

@@ -430,7 +430,7 @@ function clone(url::String, name::String = "")
end

function dir(pkg::String, paths::AbstractString...)
@warn "`Pkg.dir(pkgname, paths...)` is deprecated; instead, do `import $pkg; abspath($pkg, \"..\", \"..\", paths...)`." maxlog=1
@warn "`Pkg.dir(pkgname, paths...)` is deprecated; instead, do `import $pkg; joinpath(dirname(abspath($pkg)), \"..\", paths...)`." maxlog=1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the dirname call you don't want the .. anymore.

Copy link
Member Author

@stevengj stevengj Jul 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You still need .., because dirname will return the src directory, while Pkg.dir returns the parent directory.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, gotcha.

@ararslan
Copy link
Member

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)?

@stevengj
Copy link
Member Author

which(module)?

@StefanKarpinski
Copy link
Member

Maybe where(m) instead?

@ararslan
Copy link
Member

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.

@ararslan
Copy link
Member

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.

@stevengj
Copy link
Member Author

stevengj commented Jul 30, 2018

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.

@stevengj
Copy link
Member Author

stevengj commented Jul 30, 2018

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.)

@ararslan
Copy link
Member

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.

@StefanKarpinski
Copy link
Member

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.

@JeffBezanson
Copy link
Member

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

@stevengj
Copy link
Member Author

@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.

@ararslan
Copy link
Member

ararslan commented Jul 30, 2018

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.

@stevengj
Copy link
Member Author

Changed to pathof.

@fredrikekre
Copy link
Member

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

@stevengj stevengj changed the title add abspath(::Module) add pathof(::Module) Jul 30, 2018
@ararslan
Copy link
Member

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?

@StefanKarpinski StefanKarpinski merged commit e6c789a into master Jul 31, 2018
@StefanKarpinski StefanKarpinski deleted the sgj/pkgdir branch July 31, 2018 15:51
@ararslan
Copy link
Member

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

quinnj referenced this pull request in JuliaRobotics/LCMCore.jl Aug 2, 2018
@JeffBezanson JeffBezanson removed the triage This should be discussed on a triage call label Aug 16, 2018
@tpapp tpapp mentioned this pull request Oct 14, 2018
KristofferC pushed a commit that referenced this pull request Feb 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packages Package management and loading
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants