Simplify `protostar.toml`

[kasperski95]

As a StarkNet contract developer, I want protostar.toml be more intuitive, so that I don't have to check docs every time I want to modify something.

The current structure is the result of introducing "CLI based configuration" later in the project.

• remove ["protostar.project"] section
  • install, update, remove commands should accept libs_path as an argument
• rename ["protostar.shared_command_configs"] to something shorter:
  • [protostar.shared], [protostar.general], [protostar.default], [protostar.project](my fav)
  • this section should be auto generated by the protostar init
    • protostar init should include a comment explainig this section
• remove ["protostar.config"]
  • move protostar_version to [protostar.project] or shared/general whatever
  • rename protostar_version to min_protostar_version
  • initially protostar_version was meant to be named version and indicate version of the protostar.toml
• remove double quotes from sections e.g. ["protostar.test"] -> [protostar.test]
• protostar implementing this task should throw an error if the declared protostar_version is lower
• use kebab case everywhere
• remove ["protostar.contracts"]?

# In this section you can set any argument from any command. <= comment generated by protostar init
# e.g.
# ...
[protostar.project] # <= protostar.config + protostar.project + protostar.shared_command_configs
min-protostar-version="9.9.9" # <= extra field not available from the CLI
libs-path="..."
no-color=true
cairo-path=["...", "..."]

# Some comment explaining this section generated by `protostar init`
[protostar.contracts] # <= consider redesigning `build command` so that this section can be removed and to allow building specific contracts rather than the whole project 
# ...

# commands configuration...
[protostar.test]
# ...

[MaksymilianDemitraszek]

remove ["protostar.project"] section install, update, remove commands should accept libs_path as an argument

This is a good idea, we may provide it in the default config

rename ["protostar.shared_command_configs"] to something shorter: [protostar.shared], [protostar.general], [protostar.default], [protostar.project](my fav)

[protostar.project] is the best imo too

rename protostar_version to min_protostar_version

I dont think it's very nice, it is more like a source_version (which is terrible name). min_protostar_version does not suggest puropose of this field properly.

Generally very nice proposal!

[mkaput]

rename protostar_version to min_protostar_version

I dont think it's very nice, it is more like a source_version (which is terrible name). min_protostar_version does not suggest puropose of this field properly.

what about this?

[protostar.project]
protostar = "9.9.9"
libs-path = ["..."]
cairo-path = ["..."]

---

I am also out of the loop, but I wonder why there is the protostar. prefix everywhere?

[MaksymilianDemitraszek]

protostar = "9.9.9"

hmm maybe it's better? this field is created_with_protostar_version but it is too wordy

protostar. prefix everywhere?

to mimic poetry i think?, we can get rid of it i guess?

[mkaput]

protostar. prefix everywhere?

to mimic poetry i think?, we can get rid of it i guess?

Poetry has the prefix because they are operating in pyproject.toml which is tool agnostic. Here we have protostar.toml which is tool specific.

I think we could always use some kind of extra or metadata prefix for third party tooling. @kasperski95 opinions? :)

[kasperski95]

protostar = "9.9.9" hmm maybe it's better? this field is created_with_protostar_version but it is too wordy

IMO this property is confusing for users (and for me). Should they update the version everytime they upgrade the Protostar? It should be clear why do we need this property.

[MaksymilianDemitraszek]

Maybe we can just name it config-version and put protostar version there? Users don't have to know how we handle it

[mkaput]

I believe the only thing we can put in protostar.toml is a minimum protostar version field, which will let users know their other peers which Protostar version is needed.

[MaksymilianDemitraszek]

What is left to close this issue?

[kasperski95]

The integration with the existing code and enabling migrate-config-file command.