Pop Build - Parachain/Contract cargo project detection on current working dir

[weezy20]

A discussion rather than an issue.

Currently, if pop build is invoked without a path, it builds any cargo project in the current working dir:

pub fn build_parachain(path: Option<PathBuf>) -> anyhow::Result<()> {
	cmd("cargo", vec!["build", "--release"])
		.dir(path.clone().unwrap_or("./".into()))
		.run()?;
	Ok(())
}

This is fine if the current working dir is a parachain project, but is unexpected or unintended behaviour when invoked in some other cargo project. pop build, for the sake of correctness, should be ideally scoped only to build contract and parachain cargo projects.
I understand that this is not really a problem, but this issue is meant for discussion on if it's worth the additional code or not.

[AlexD10S]

Is a good point, as you mention pop-cli should be scoped only to build contract and parachain cargo projects. So I am in favor of adding a check and show an error to the user if the path is not a contract or parachain project

[Daanvdplas]

Yes agreed, I think checking for contract / parachain specific files in the root of the project is a start. E.g.:

1. contract: Cargo.toml file with ink depenedency
2. parachain: node/, runtime/ folders

[weezy20]

@Daanvdplas I like the approach. I believe that we should do the same as in contracts, i.e. check for substrate linked dependencies, such as frame-support or frame-system for runtime and sc-* deps for node. We could also check for the folder structure node/, runtime/, however a weird edge case might be someone uses pop build with a substrate project that calls them my-node and my-runtime. It's good to think of solutions that can handle worst possible case.

[Daanvdplas]

I have never seen a project where the folders are not called node/ and runtime/. Therefore I suggest we keep it simple and start with the above approach. Time will tell if we need more advanced searching

[weezy20]

@Daanvdplas quick example:

1. https://github.com/Polkadex-Substrate/Polkadex.
2. https://github.com/paseo-network/runtimes
3. https://github.com/aleph-zero-foundation/aleph-node
   As you can see, projects using multiple implementations in this case can call it something else: nodes, runtimes or even have it in separate repositories. It's unwise to assume every substrate project would follow the same directory naming conventions.

[Daanvdplas]

Oke, perhaps a dependency like sp-runtime (found it in the node and runtime after having a quick look) ?

[AlexD10S]

Adding a check to detect if the user wants to build a parachain a contract.

As discussed here #129

For the pop build command the user won't have to type parachain or contract