Pluto.jl using with custom project gets workspaces mixed up

General Usage
1

I want Pluto to use my current project Tibra.jl so I do Pkg.activate(.) then import my project.

Problem is I can’t access any of the exported types from my package in a Pluto cell so I try to use Reexport. I’m not sure if this is necessary.

begin 
    using Pkg
    Pkg.activate(".")

    	using Reexport
        include("../src/Tibra.jl")
	@reexport using .Tibra

Now I am trying to write a function that uses one of the types from my project but im getting convert errors that it can’t convert from one workspace type to the other. Not sure why multiple workspaces are being created here.

2

It would be better to add/dev your package rather than include a source file from it.

Like this:

import Pkg
Pkg.develop(path="/path/to/Tibra-repo")

And if you want to mix other packages with Pluto’s package manager, you can workaround that like so:

import Pkg
dev = Pkg.develop
dev(path="/path/to/Tibra-repo")
2 Likes
3

Ok did that and now I’m getting:

package Tibra [e0da2792] has the same name or UUID as the active project

4

Don’t activate the project

5

After restarting the Pluto server it works without above error. However, I still have the problem that the packages I installed in Tibra.jl are unavailable to the notebook.

It’s asking me to install them one by one.

6

Why do you want to do that, just convenience? Usually packages inside a package aren’t directly made available. But, I think you should be able to access them via Tibra.PackageName, because the symbol is defined within Tibra.

If you want Tibra to re-export, though, Tibra should use Reexport.jl internally.

7

So I have to individually @reexport every imported package in Tibra? That seems wrong.

I want to do it so I don’t have issues when importing the packages. It doesn’t seem to want to download packages after calling Pkg.develop()… or is that because I had run Pkg.activate() at some point? I have to check.

8

What are you trying to do in Pluto? Are you trying to develop your package, or use it?

The workaround I mentioned above dev = Pkg.develop is necessary if you want to install other packages using Pluto’s package manager.

9

Im trying to develop my package by actively adding code to it then trying to get the updates in Pluto without a kernel restart. I should also be able to use my package objects in Pluto.

10

Unfortunately if you want to still use the integrated package manager you have to manually add all the packages that are used by your module to the notebook.

I understand your approach of using Pluto as a way of fast-track part of the development (especially at the beginning) and avoid having to always restart the kernel when you modify a struct (hopefully Revise will support that at some point).

I also find it useful to exploit Pluto reactivity to always see the outcome of my code modifications to internal functions automatically by putting some check cells that execute the function I am modifying.

That being said, I think it would be worth for you to look at the package I am developing:

It’s directly aimed at simplifying building packages from Pluto notebooks.

There is a @plutoinclude macro that can be used to include julia files or notebooks and have them accessible within the notebook, with the possibility of reloading them (manually) when you changed the code in those dependent files.
You can have a look at the readme and example in the package or also have a look at how I use it in another package of mine (GitHub - disberd/TelecomUtils.jl) where all the package is developed as part of interdependent notebooks.

I have been actually going through an upgrade of PlutoDevMacros to simplify the whole notebook inclusion or file inclusion so that it’s easier also to specify a path to a repo to include like you wanted to do in the original post.
It will be a new macro that to some extent will render @plutoinclude obsolete for most of my use cases.
It is still not finished though so you can’t use it yet.

2 Likes
11

Sounds great! Will give your tools shot and report back.

12

Nice timing @bryaan!
I just finished putting up together the first version of the other macro I was mentioning, now (after automerge) available in v0.5.1 of the package.

You can find details of the added functionality in the update README

You can also have a look at the various test notebooks in the TestPackage under test/TestPackage for some usage examples

1 Like