chore(pact-project-proposal): initial proposal #1686
Conversation
alber70g
commented
Feb 20, 2024
•
alber70g
commented
- To see the specific tasks where the Asana app for GitHub is being used, see below:
- https://app.asana.com/0/0/1206645620274001
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
| dependencies (recursively through `dependencies`) | ||
| - `path`: the path to the contract that needs to be available for the | ||
| depending project to work | ||
| - `dependencies`: a list of object that define this contracts' dependencies. |
There was a problem hiding this comment.
So this makes sense, but we need to tease out some structure here:
- What does it mean to be a unit of distribution, as in, what is considered a singular, self-contained unit that can be delivered via its source code and deployed on the blockchain in an automatic fashion? I think this is a good start. You'll also probably want to include the install script (
tx.yamlor smth) as a field in this distribution. I imaginedeploywould only understand how to upload and deploy to a network if that were present. - What does it mean to be a project, distinct from a unit of distribution? I would deploy a unit of distribution, but what would i build upon? A project, to me, should contain the following:
- A list of dependencies, and a specification for where they're being stored, whether we have a default location local to the project, or user-specified.
- A distinction between source and test directories, and tools to test that i could compose with deployment to build a CI/CD pipeline.
- directories I could specify to dump FV or coverage artifacts
Together, i think 1 and 2 would be enough of a start to talk about a fully fledged "Pact Project" .
HTH
| "description": "Chainweb Pact Project", | ||
| "source": "[email protected]:kadena-io/chainweb-pact.git", | ||
| "dependencies": [ | ||
| "[email protected]:other-user/my-other-dependency.git" |
There was a problem hiding this comment.
I like the idea of content address-ability here. We should figure out how to reference contract hashes directly with some nice syntax. Having github support would be killer to mix with that.
There was a problem hiding this comment.
Another thought a day later: supporting commit hashes, as opposed to git repos would be preferable.
There was a problem hiding this comment.
I'd like this to be similar to how NPM allows to use dependencies. This includes various ways of specifying versions, git urls, github urls (kadena-community/a-repo#commit-sh) etc
https://docs.npmjs.com/cli/v10/configuring-npm/package-json#dependencies
There was a problem hiding this comment.
That's fine by me, but we should specify the variations in syntax that we plan to support beforehand.
| "dependencies": [ | ||
| { | ||
| "path": "./some-other-contract.pact" | ||
| } |
There was a problem hiding this comment.
hash or checksum would be nice to include here.
|
This PR is stale because it is open for 60 days with no activity |
|
This PR is stale because it is open for 60 days with no activity |
