Location field autofill

[flip111]

Would be nice if the location field could be filled as far as it is possible. One would have to run this command git ls-remote --get-url origin, if the remote is not origin then i would further not support automatic detection.

[f-f]

This goes together with #1056

[fsoikin]

I'm not sure I understand. At which point should it be autofilled? And what does "autofilled" mean in this context? Just use that information in lieu of missing config? Or actually update the config?

[f-f]

I was thinking about actually updating the config. Not sure how exactly that would work out though - the type of the publish section of the config looks like this:

spago/core/src/Config.purs

Lines 95 to 101 in c4c9641

	type PublishConfig =
	{ version :: Version
	, license :: License
	, location :: Maybe Location
	, include :: Maybe (Array FilePath)
	, exclude :: Maybe (Array FilePath)
	}

So if we don't have a version and a license then it doesn't make sense to proceed further.
But if we have those already then we could populate the configuration (we already do plenty of that) with the info gathered from the git remote, possibly issuing a warning to the user about that

[fsoikin]

Ok, just to clarify: does "auto-filling" involve writing the config back to disk? Or only adding it in memory after the config is read?

Also: is there a particular reason for doing all that patching in JS? Without any more context, I would assume this kind of patching should be part of the codecs.

[f-f]

does "auto-filling" involve writing the config back to disk? Or only adding it in memory after the config is read?

Generally we write the config back to disk (so it persists) and also update the data in memory so that execution can move forward, but in this particular case I think we should just write to disk and add an error to the pile: the user still needs to commit the new config before publishing can happen.

Also: is there a particular reason for doing all that patching in JS? Without any more context, I would assume this kind of patching should be part of the codecs.

This is something that should be better documented in our "dev" docs (which right now is the CONTRIBUTING.md file, but we could also have a HACKING.md or ARCHITECTURE.md).

Basically we want to preserve formatting and comments in the yaml configs we write back to disk. We also want to reuse the JSON codecs to parse/deal with the yaml configs, which are not rich enough to store all that info.
So we read the yaml with the yaml library, keep a hold of the Document that it returns, and then go ahead and parse its JSON representation with the JSON codecs.
When we need to update the config on disk we then act on the Document in JS land, which preserves formatting and comments when updated with the API we use.
We could model all of this in PureScript land, but I don't think the additional type safety justifies the ton of work that it would entail.