`,
1. define `Foo.examplepath(...)` using `@ __DIR__ ` (recommended solution),
2. use `Base.pathof(Foo)`.
---
### Author:  [@krcools](https://discourse.julialang.org/u/krcools)
#### Post date: [August 13, 2018, 1:55pm UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/7 "2018-08-13T13:55:48Z")
This is a solution but you will agree it adds a significant overhead compared to the steps required in Julia-0.6. I would argue your solution expands to:
- Read `hello.jl`, or let’s call it `demo_all_pkg_features.jl` to stress there are cases in which the user is not necessarily interested in the details of the code contained in the example.
- Correctly list and add all dependencies. Users might find this difficult or might be unwilling to pollute their primal environment.
- Then after all installations complete:
```julia
using Foo # yet another step not required in 0.6
d = include(Foo.examplepath("hello.jl"))
```
Given how lightweight projects and environments have become I was really hoping for a much more idiomatic solution to this very common problem.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [August 13, 2018, 2:09pm UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/8 "2018-08-13T14:09:39Z")
> [@krcools](#):
>
> you will agree it adds a significant overhead compared to the steps required in Julia-0.6
Nope, I don’t agree.
> [@krcools](#):
>
> Read `hello.jl` , or let’s call it `demo_all_pkg_features.jl` to stress there are cases in which the user is not necessarily interested in the details of the code contained in the example.
Sorry, I don’t understand what you are saying here. If the user is not interested in the example code, then what purpose does it serve?
> [@krcools](#):
>
> Correctly list and add all dependencies. Users might find this difficult or might be unwilling to pollute their primal environment.
Again, installing a package is just a single `add` command. `Pkg` will install the dependencies. In case the example requires an additional package, that should be installed, too. I think this is trivial.
Also, I don’t really see the issue about “pollution” of the environment, but if the user is concerned about that, they should `activate` another one.
Finally, I don’t see the point of `include`ing an example. I would just open it in the editor, and send it to the REPL line by line to understand what is going on.
---
### Author:  [@krcools](https://discourse.julialang.org/u/krcools)
#### Post date: [August 13, 2018, 2:37pm UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/9 "2018-08-13T14:37:17Z")
> Sorry, I don’t understand what you are saying here. If the user is not interested in the example code, then what purpose does it serve?
Someone might be looking for a good plotting package. Often the example showcase what type of plots are in store. At this point I just want to know whether this package can give me a histogram with transparent bars. I don’t want to worry about whether or not I need e.g. `GeomTypes` whilst shopping for a plotting lib. Just running examples can also give a good idea w.r.t to the package performance.
In `GLVisualize`, the authors support prospective users by leveraging the testing infrastructure of Julia. In this case, a oneliner:
```julia
pkg>test GLVisualize
```
will resolve additional dependencies (and expose them top-level if needed), create a separate environment, instantiate it, and include the tests (or interactive demos as is the case for `GLVisualize`).
In my opinion it would be convenient for this functionality to be extended to something like:
```julia
pkg>example Foo hello
```
I agree just running the examples it too limiting. Maybe in addition to what happens when testing, the examples could be copied over in a directory with a predictable name (or custom name), similar to what happens when you `develop` a package.
Given the flexibility of the new package manager and the how common it is for packages to ship with an examples subdirectory I was just wondering whether someone had automated something like this.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [August 13, 2018, 3:17pm UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/10 "2018-08-13T15:17:46Z")
> [@krcools](#):
>
> Often the example showcase what type of plots are in store. At this point I just want to know whether this package can give me a histogram with transparent bars.
Presumably the documentation or the main page of the project on Github etc would be a good starting places for this information. Eg [PGFPlotsX does this](https://kristofferc.github.io/PGFPlotsX.jl/latest/examples/gallery.html).
However, if you want code in a directly executable form, probably packaging the demo itself as an additional project would be a viable solution.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [August 13, 2018, 4:19pm UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/11 "2018-08-13T16:19:45Z")
> [@krcools](#):
>
> I understand there is an unexported and undocumented `Base.find_package` that alleviates this to some extent?
You do this:
```julia
julia> using StaticArrays
[Info: Precompiling StaticArrays [90137ffa-7385-5640-81b9-e52037218182]
julia> pathof(StaticArrays)
"/Users/stefan/.julia/packages/StaticArrays/Ze5H3/src/StaticArrays.jl"
```
The difference is that you have to pass the package module rather than its name.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [August 13, 2018, 4:25pm UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/12 "2018-08-13T16:25:30Z")
> [@Tamas\_Papp](#):
>
> Also, I don’t really see the issue about “pollution” of the environment, but if the user is concerned about that, they should `activate` another one.
Moreover, the targets mechanism makes it easy for the package to declare project environments that extend its own, just do:
```toml
[extras]
Bars = ""
[targets]
examples = ["Bars"]
```
We still need an API to activate target environments (`pkg> activate Bars.examples`)?, but with that you could just do that and you’ll be able to run the examples from that environment easily.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [August 13, 2018, 4:52pm UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/13 "2018-08-13T16:52:25Z")
At a very high level, this issue is about whether `Bars` is an internal implementation detail of `Foo` or if it is part of `Foo`’s external API. In general, one does not want a package’s dependencies exposed to its users since doing that prevents it from changing its implementation in the future. The new package manager and code loading mechanism takes a very hard stance on this: dependencies are an internal implementation detail and are private. To the point that one of your dependencies can have a dependency with the same name as one of your project’s dependencies even if it is actually a different package.
Running package examples is definitely something we need to work out how to do conveniently, but it does not take precedence in importance over keeping a package’s internal implementation details isolated and private. I’m not saying that to chastise but to frame this conversation appropriately: rather than complaining about / trying to redesign the code loading so that this one relatively marginal thing can be done as easily as possible, try to think about how to make running example code easy, taking the way code loading now works as a fixed point—since it is not changing now that 1.0 is released.
---
### Author:  [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)
#### Post date: [August 14, 2018, 6:20am UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/14 "2018-08-14T06:20:30Z")
Is the strategy to re-export relevant parts of `Bars` from `Foo` a reasonable alternative, considering that users of `Foo` are expected to know about and use `Bars`? Or this is no longer possible the way it was in 0.6?
If it is a reasonable strategy, is [Reexport.jl](https://github.com/simonster/Reexport.jl) a good option? I see it has been updated recently to support Julia 1.0, but have heard some loose arguments against use of it before.
---
### Author:  [@krcools](https://discourse.julialang.org/u/krcools)
#### Post date: [August 14, 2018, 7:29am UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/15 "2018-08-14T07:29:25Z")
I very much welcome the strictness of the package manager. What I was looking for was something built on top of the current framework, like the solution you mention is in the works.
I don’t think the situation I described necessarily comes from `Foo` exposing its implementation. The situation I found myself in is with `Foo` a library that is designed to do processing on objects implementing the Bar concept (concept as in the c++ meaning of the word). Package `Bars` defines the concept by (i) introducing a set of functions meant for other packages to extend, and (ii) providing a reference implementation `Bar` accompanied by unit tests that guard the semantics of what it means to be a Bar.
A bad example of this is the Array concept in `Base`. `Base` introduces the _original_ `getindex` etc, but also includes the reference implementation `Array{T,N}`. As a result, many other packages both import `Base` and allow objects from `Base` to be passed to the API. This example is bad because `Base` is the one package the manager lets you have for free.
As another example I could think of a package `Fields` defining the mathematical concept of field by introducing say `mult_inverse` etc. and providing the reference implementation `Galois{P}`. Then another package `LinearSpaces` comes along that will have to import functions from `Fields` to implement say `elementwise_addition`. It is very like `LinearSpaces` will also include `Fields` in its suite of examples. I wouldn’t say in this case the packages needlessly expose implementation details.
---
### Author:  [@jdlara-berkeley](https://discourse.julialang.org/u/jdlara-berkeley)
#### Post date: [August 24, 2018, 11:20pm UTC](https://discourse.julialang.org/t/best-practices-for-examples-with-pkg3/13356/16 "2018-08-24T23:20:03Z")
Since `test` can be defined as a target, how about `build`? In some cases, one could need some packages, specially Pkg itself just for building and wouldn’t want to include it as a dependency in the project.