Reasonable defaults for other languages
hawkins opened this issue · 3 comments
You knocked #15 out of the park in record speed, so I thought I'd ask the follow-up question: Is it reasonable to include reasonable defaults for things like name, repository, etc for other package manger configs?
You support .fiddly.config.json
for everything now which is 💯 and really all we need to support packages in arbitrary other programming languages, but you also can infer from package.json
. What would you say to supporting other popular dependency manager files, such as Cargo.toml
for rust, *.gemspec
for ruby?
Immediate issue that comes to my mind is parsing these other formats. Because of that, I think it's totally reasonable in my mind to say this is out of scope, but at the same time it could really take that "no-config" ability of Fiddly to another level if you're open to it. 🤷♂️
Hey !
For toml files it's quite easy if I use something like: https://github.com/iarna/iarna-toml
I have no idea for *.gemspec
files.
Do they have defined structure ?
I'm in for it. This is a great idea in my opinion
Is it this?
Gem::Specification.new do |s|
s.name = 'example'
s.version = '0.1.0'
s.licenses = ['MIT']
s.summary = "This is an example!"
s.description = "Much longer explanation of the example!"
s.authors = ["Ruby Coder"]
s.email = 'rubycoder@example.com'
s.files = ["lib/example.rb"]
s.homepage = 'https://rubygems.org/gems/example'
s.metadata = { "source_code_uri" => "https://github.com/example/example" }
end
Yeah, that's the gem spec. I think that's actually technically just Ruby language, though, so not any kind of "Gemspec" language. Lots of them actually dynamically pull in ruby code above the Gem::Specification
block (especially version), so this may be a minefield for Ruby.
But, we could at least try a basic ruby parser or hack job regex to try to find what can be statically inferred without reading ruby's require statements.
Or maybe that's too dicey and we cut Ruby out of first-class support for stability sake