I think the file does not get evaluated in the current environment, but rather the environment that it is located in. You could try checking whether it works after you explicitly activate the environment in the file something like `using Pkg;Pkg.activate(“/pathTo/TestPkg”)
edit: Forget the above, the environment should remain. Maybe the reason is that your method creates just an environment which is not quite the same as a package that can actually be included? I am not entirely sure.
In any case, do you know that you can create a new Package simply via ]generate TestPkg instead?
After that works, maybe as a further check in between you could try
]activate TestPkg
using TestPkg
If that also works, you can create your test file. By the way, another way to test your package is to run ]test TestPkg. Then it seems the testing file is executed in the correct environment.
I think your approach should also be fine though and its probably easier to test during your development flow (Assuming you also use Revise).
Hope that helps
I know there are generate PkgName and PkgTemplates that can automatically generate the required files and create the right environment; however, I was just curious to see what if I do it manually. In theory, it should still work.
Anyway, what I found was the way I was doing is not wrong, but my steps missed the part of specifying the name of the package in the Project.toml file. My Project.toml file looked like
Although it is true that uuid will be required but it’s not mandatory at the development stage. What I mean is I was able to resolve the error I mentioned just by adding the name of the package in Project.toml file. Correct me if I am wrong. In short, I can work on the package (code and run it successfully from within its own environment) as long as I have its name specified in the Project.toml file.
And as you mention in the tutorial we can use using UUIDs; uuid4() to generate one when we want. Thanks for the reference to your tutorial though. I will keep an eye on it!