Package usage interface

[Jacek Generowicz]

Is my understanding correct that a package called 'Frob' is expected to
have a top-level module called 'Frob', and that, in order to use it, one
is expected to

1. load("pkg") # once per "Julia installation"
2. Pkg.add("Frob") # once per package
3. require("Frob") # in the client code that uses Frob
4. using Frob # optional ?

?

What does Frob's author have to do to ensure that 3. finds the right
code (which is, presumably, METADATA/Frob/src/Frob.jl)?

[Jason Knight]

require(...) is defined in base/util.jl. It is currently identical to load(...), so if you see that in places, the two are the same for the moment. 

require(...) uses find_in_path (also defined in util.jl) to search the LOAD_PATH (which is defined in client.jl), for the given module. By default LOAD_PATH includes the julia_pkgdir() which is where Pkg.add(...) puts things.

julia_pkgdir() is also in base/client.jl, and is either the environment variable JULIA_PKGDIR or $HOME/.julia.

Hope that helps!

Jason

[Stefan Karpinski]

1. load("pkg")      # once per "Julia installation"

3. require("Frob")  # in the client code that uses Frob

Load and require are the same thing, as Jason said. load("pkg") loads the Pkg machinery for installing and updating packages. require("frob") looks for the frob.jl file in LOAD_PATH.

 

2. Pkg.add("Frob")  # once per package

This asks the package manager to install Frob. Once it's installed, you don't need to do this anymore.

 

4. using Frob       # optional ?

This tells julia that when looking up names in the current namespace, it should look in the Frob namespace as a fallback for undefined names. 

[Jasper]

As i understand it, in the future `using Frob` will automatically do
what `require("frob")` does.

[Jacek Generowicz]

Stefan Karpinski writes:

> require("frob") looks for the frob.jl file in LOAD_PATH.

What is the canonical procedure for ensuring that your package's
location is present in LOAD_PATH?

[Tim Holy]

If it's a registered package (with METADATA.jl), it will be found as long as
you've added it through the package manager.

You can also explicitly add paths in your ~/.juliarc.jl file: push(LOAD_PATH,
newpath)

--Tim

[Jacek Generowicz]

Jacek> What is the canonical procedure for ensuring that your package's
Jacek> location is present in LOAD_PATH?

Tim Holy writes:

> If it's a registered package (with METADATA.jl), it will be found as long as
> you've added it through the package manager.

I'm sorry for being really dense: When creating a packgage, what can be
done locally to check whether everything has been done according to
requirements/expectations, so as to avoid polluting the outside world
with a horribly broken package?

Is there an idiot-proof list of steps somewhere?

There's just too much magic and mystery in this package manager for my
limited intellectual capabilities, and the apparently copious, shared,
distributed, mutable state scares me witless.

[Patrick O'Leary]

On Tuesday, December 18, 2012 9:00:12 AM UTC-6, Jacek Generowicz wrote:

I'm sorry for being really dense: When creating a packgage, what can be
done locally to check whether everything has been done according to
requirements/expectations, so as to avoid polluting the outside world
with a horribly broken package?

The following must exist:

METADATA/YourPackage/
METADATA/YourPackage/url # contains a single line with public fetch URL
METADATA/YourPackage/versions/
METADATA/YourPackage/versions/0.0.0/
METADATA/YourPackage/versions/0.0.0/require # copy of REQUIRE
METADATA/YourPackage/versions/0.0.0/sha1 # contains a single line with hash

Is there an idiot-proof list of steps somewhere?

Read through Pkg.new() in base/pkg.jl, but no guarantees for idiotproofness.
 

There's just too much magic and mystery in this package manager for my
limited intellectual capabilities, and the apparently copious, shared,
distributed, mutable state scares me witless.

Me too. I'm still not comfortable with the copied state myself; inconsistencies just between a package and METADATA seem likely to break something eventually. But I'm giving Stefan the benefit of the doubt for the moment.