Running project tests about drwatson.jl

[asinghvi17]

I think we could probably initialize it with a src/PkgName.jl and a UUID, wouldn't be too hard a change.

We could possibly integrate with PkgTemplates.jl as well, for CI templates and whatnot.

[KristofferC]

The way I always structured my code when doing projects in the scientific context was that the main code, for example the code that runs the simulation was a package with a Package.jl file and Project.toml file. So it would look something like

module CrystalPlasticitySimulator

struct Model
    ...
end

struct MaterialParameters
   ...
end

function solve_model(m::Model, mp::MaterialParameters)
   ...
end

function export_data(solution)
   ....
end

My "experiments", i.e., numerical simulations with a certain set of material parameters was then in a script folder and looked something like

import CrystalPlasticitySimulator

m = CrystalPlasticitySimulator.Model(:dual, ...)
mp = CrystalPlasticitySimulator.MaterialParameters(E=200e9, ...)

solution = CrystalPlasticitySimulator.solve_model(m, mp)
CrystalPlasticitySimulator.export_data(solution)

I had one of these files for each numerical example in the paper.

Anyway, I guess there shouldn't be anything stopping being able to Pkg.test something that doesn't have a UUID. So feel free to open a feature request about that on the Pkg repo.

[sebastianpech]

Sounds good! Thanks for opening the feature request

[Datseris]

Damn. :( The problem you mention here is the same as here: #61

---

Here is why I don't like the UUID approach:
From my perspective a project created by DrWatson is not supposed to be a Julia package, which is why it doesn't have a UUID. It is supposed to be a Julia project. I believed these two concepts are clearly distinguished, but if you don't think so maybe I should reconsider...

I also don't think creating a PackageName.jl -like file makes sense. A scientific project more often that not will try to implement several functionalities and pipelines to answer the scientific questions. I doubt this would typically be possible to do with a single module named PackageName. See the discussion here as well : #62

Such discussions like the one here is also why I was very skeptical of: #40 (although I never expressed the skepticism back then) , because it also tries to make the project initialized by DrWatson more like a Julia package.

---

I will be honest. I Think the problem that you mention here as well as in #61 is a bug from the package manager. In principle I see no reason to not be able to run the tests of a project even if the project itself is not a Julia package, but only a Julia project (i.e. no UUID). Similarly, I see no reason to not be able to build a project's packages if the project itself is not a Julia package. I mean, how does it work for the "standard Global project, e.g. 1.1"?

I'll take the liberty to tag @KristofferC , maybe he can give some comments.

[sebastianpech]

Fair point. Also the docs for Pkg state

A package is a project with a name, uuid and version entry in the Project.toml file, and a src/PackageName.jl file that defines the module PackageName. This file is executed when the package is loaded.

So in terms of phrasing this is not a project anymore.

Creating the PackageName.jl doesn't make any sense. A proper solution without needing to add a UUID and especially the extra jl file would be nice. Let's see

[Datseris]

This is also what we do in DrWatson, but we wrap the entire process in a Julia package project, so that it can be also tied with the exactversions of other installed packages that it uses and be shareable. In addition, this allows you to nicely navigate folders based on the Project.toml file and some other benefits (no reason to go into details here).

The project itself contains one (or several) packages, as described here: #62

In my eyes the way to move forward would be to wait for test or build to be possible to be done on normal projects JuliaLang/Pkg.jl#1253