FPM Spec files

[arussellsaw]

after reading through the docs and command arguments, i had a thought that it would be great if we could define these arguments via something like JSON, to make builds cleaner, as at the moment most of my projects contain a build.sh with a long command specifying options. if i could define something along the lines of packagename.fpm, or something Fpmfile (a la Vagrantfile) , and run fpm packagename.fpm to produce the desired package. an ideal world would just be a JSON structure that maps closely to the existing arguments.

example proposed structure:

"a-packagename": {
    "source": "python",
    "target": "rpm",
    "dependencies": [
         "python-requests",
         "python-dateutils"
    ]
    "python-options": {
         "bin-path": "/usr/bin/python2.7",
         "lib-path": "/usr/lib/python2.7/site-packages"
    }
}

[miked63017]

Its not json, but this is kind of what your asking for https://github.com/jordansissel/fpm/issues/509

I think json and yaml were both discussed but decided against. FWIW I am not opposed to being able to use more than one format, but that links merge request helped me clean up my build scripts pretty nicely without json.

[v6]

// , Got any advice for us FPM users on ways to clean up build scripts that way, @miked63017?

Or advice on how to build 'em right in the first place?

[miked63017]

We put more common vars in the dot files, and the rest we put in a shell script. Each build is in its own git repo, and we do versioning on the packages by shell escaping a date command so that every build is newer than the previous. I don't know if this methodology is "right", there's always room for improvement, but its working pretty well for us. On Sep 15, 2015 5:18 PM, "Nathan Dataguake Basanese" < notifications@github.com> wrote:

// , Got any advice for us FPM users on ways to clean up build scripts that way, @miked63017 https://github.com/miked63017?

Or advice on how to build 'em right in the first place?

— Reply to this email directly or view it on GitHub https://github.com/jordansissel/fpm/issues/881#issuecomment-140562099.

[hatt]

The way we use FPM in my workplaces has been an fpm dotfile local to the repo to set all the standard stuff, and just pass the package name/version via CLI from git tags. I don't think there is a right answer as such but I really don't understand why so many people are asking for an FPM spec format. Very little data is actually changing so having a wrapper that's consistent is fine, or just use a dotfile. A config or spec file would actually be more verbose than just using the dotfile in the first place.