Comments (18)
I would like some clarification just to better understand your proposal. At the moment, the repositories scaffolded to be used as modules rather than webhapps still contain a happ.yaml
and dna.yaml
despite not really needing one, since the consuming happ would import them as rust dependencies from my interactions with the profiles and file storage zomes.
Maybe if the scaffolding tool could first scan for happs, fall back to find DNAs, and lastly fall back to finding zome
I am not sure about this, since we would still need to keep the "fake" happ.yaml
and dna.yaml
files, which I wonder would really be needed in such a case.
What do you think about having a separate command i.e hc-scaffold module
?
from scaffolding.
Mmm yes you are mostly right. But why would we need to keep the dna.yaml
and happ.yaml
files? I have an alternative way in which I produce the DNA and happ bundles without them.
What would hc scaffold module
do? What I really need is to be able to do hc scaffold entry-type
in that kind of repository where there are only zomes.
from scaffolding.
What would hc scaffold module do?
I'm seeking a better understanding on whether it's still appropriate to use hc scaffold web-app
to scaffold a module instead of a web app
from scaffolding.
But why would we need to keep the dna.yaml and happ.yaml files?
I agree with the decision to no longer require the dna.yaml
and happ.yaml
files for these kind of repositories. I'm curious about the process for generating the DNA and hApp bundles. I'm assuming the bundles would be produced by the web-hApp consuming this module, right?
from scaffolding.
Yeah that's right. I have a method of generating DNA manifests in nix https://github.com/holochain-open-dev/infrastructure/blob/97a15932e38a3a0db5ce5b48b4989508bf91bb46/nix/fixtures/module-repo/zome/zome.nix#L18 that allows me to generate fake DNAs as needed without needing a dna.yaml file. So in the repository where the zome lives, there is no happ.yaml or dna.yaml but you can still test your app.
In the consuming repositories, there you include the zomes into your dna.yaml to actually build your app, like this. Do you have any other questions about the pattern?
from scaffolding.
I see, this is quite new to me
I am curious to know how the proposed method is different from what I have used before from this guide. Do they both achieve the same goal?
from scaffolding.
So in the repository where the zome lives, there is no happ.yaml or dna.yaml but you can still test your app.
Also another question regarding this; the fake manifests getting generated are only useful for testing within the zome's repository context, right?
from scaffolding.
Well, in the proposed method, you don't need actual dna.yaml or happ.yaml files, you can "fake them" in nix files so that you decide what to include and when. In zome only sweettest, I can create a DNA bundle only with the zome I want to test, which means I can test only that given zome with its integrity.
Also another question regarding this; the fake manifests getting generated are only useful for testing within the zome's repository context, right?
Yes exactly, that's the main purpose.
from scaffolding.
I see, so for such repos, the scaffolding tool should not be generating these manifest files, this is the only change required from the cli as far as I understand.
Or should "faking" the manifests in nix be handled by scaffolding as well?
from scaffolding.
Close, but not really what I mean.
If the command hc scaffold dna
is run, it's totally fine that a dna.yaml
file gets created. It is in fact necessary. The thing is that command will never be run in the kinds of repositories we are talking about.
What I'd like to change is that in repos where there's no dna.yaml
, only zomes, I can't run hc scaffold entry-type
or hc scaffold link-type
. This is because the scaffolding tool does not find any happs or DNAs, so it just errors out. I'd like for it to be able to find the zomes that do exist in the repository and choose them as the options where to scaffold the entry or link-type.
I don't think the faking the manifests in nix should be handled by the scaffolding tool no. As a matter of fact I'm scaffolding them myself in the custom template for holochain-open-dev.
from scaffolding.
What I'd like to change is that in repos where there's no dna.yaml, only zomes, I can't run hc scaffold entry-type or hc scaffold link-type.
I see, so for such repos, the workflow would remain the same except for the fact that no dna
would be scaffolded. Therefore the zome
, entry-type
and link-type
commands should still be able to run without producing this error Error: No DNAs were found
How about the happ.yaml
and web-happ.yaml
manifests, they would still get generated in this case, should these too be skipped?
from scaffolding.
Yes same, they will never get created.
from scaffolding.
Great, I can add this functionality, probably as an optional flag passed to hc scaffold web-app
to indicate this is a module.
from scaffolding.
Hmmm how is that going to change the behavior of hc scaffold entry-type
? The problematic code is here.
from scaffolding.
The problematic code is here.
Yes, this change will also be made,
I am just considering the user who scaffolds a web-app that is intended to be used as a module, the project that gets generated should not have these manifest files by default and there shouldn't be any instruction to run hc scaffold dna
Do you think this is not necessary and they can manually delete these files to turn their hApp into a module?
from scaffolding.
Ah no that is already covered with the module template, which already scaffolds only the zomes and tells you not to scaffold DNAs. It's cool that this can be done without needing to change the code for the scaffolding tool!
from scaffolding.
Ahh I see, no need to handle this on scaffolding then
from scaffolding.
@guillemcordoba, I've conducted an in-depth review of the issue and would like to share my findings:
The generation of happ.yaml
occurs upon execution of the command nix run github:holochain-open-dev/templates#hc-scaffold-module-template -- web-app
. Consequently, the absence of this file should theoretically result in the error No app manifest (happ.yaml) was found in this directory tree
when attempting to scaffold an entry or link type. This discrepancy appears to stem from how the entry-type scaffolding process attempts to "get or choose" an AppFileTree at this point in the code as well as this. These areas may contain problematic code that warrants further investigation.
A significant dependency exists between the ZomeFileTree and DnaFileTree structures. This coupling is particularly evident in functions tasked with scaffolding entry, link types, and collections, where the DNA manifest is referenced. Decoupling these components, or at least providing a default implementation for DnaFileTree in the absence of a DNA manifest, would likely require extensive refactoring. I'm curious if such an approach has been considered in your proposal, especially since addressing the initial issue you identified might not fully resolve the problem, given the presence of similar issues elsewhere in the code.
I'm keen to hear your thoughts on this analysis.
from scaffolding.
Related Issues (20)
- `tests/node_modules` not ignored by Git HOT 1
- Please upgrade `@msgpack/msgpack` HOT 3
- make dependent collections reactive HOT 3
- bug(0.3): `file_exists` helper breaks in examples
- CI actions are out of date HOT 1
- enhancement: Provide option to scaffold `dna` (and `zomes`) on running `hc scaffold web-app`
- Suggestion: Enhance Flexibility in Setting Number of Agents via Environment Variable HOT 1
- enhancement: Ensure initially scaffolded code is well formatted
- Custom template nix wrapper results in `Error: unmatching template` HOT 2
- [Feature] Link-types from AnyLinkableHash to AnyLinkableHash
- [Feature] Collections to agent keys
- bug: vanillajs should be inferred as the template when scaffolding the hello-world example
- Disable reformatting of unaffected files HOT 4
- feat: Make scaffolding cli package manager agnostic HOT 4
- chore: Upgrade material/mwc beta components to @material/web
- scaffold tool converts snake_case to camelCase for i32 fields in entry-type in vue HOT 1
- bug: Bad formatting in entry-type.rs files
- bug: UI fails to load when running `hc-scaffold` example with vue template
- fix: Add missing breaking change for `HolochainError` class instance from holochain client-js
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from scaffolding.