create-pkg.sh depends on hidden variables

[suntong]

create-pkg.sh now depends on new hidden variables that is undocumented and not explicitly passed in doc or in
https://github.com/mh-cbon/emd/blob/master/.travis.yml

From my new build log:

+[ suntong/cc2py = mh-cbon/go-bin-deb ]
+go get -u github.com/mh-cbon/go-bin-deb/go-bin-deb-utils
+go-bin-deb-utils create-packages -push -keep -repo=suntong/cc2py
2017/05/06 16:26:09 missing argument -email or env ["EMAIL" "MYEMAIL"]

[solvingj]

I wonder if @mh-cbon can comment as to whether or not these create-pkg.sh scripts need to exist long-term. I understand they were created for a reason, but generally speaking, elaborate shell scripts in the build process are problematic, and minimizing their use is a good thing when possible. I did notice create-pkg.go as well, so I'm hoping there is a desirable alternative.

[mh-cbon]

solvingJ, the script we talk about is a few lines,

#!/bin/sh -e

# this is an helper
# to use into your travis file
# golang is required.
#
# to use it
# curl -L https://raw.githubusercontent.com/mh-cbon/go-bin-deb/master/create-pkg.sh \
# | GH=YOUR/REPO sh -xe

if [ "${GH}" = "mh-cbon/go-bin-deb" ]; then
  git pull origin master
  git checkout -b master
fi

go get -u github.com/mh-cbon/go-bin-deb/go-bin-deb-utils
go-bin-deb-utils create-packages -push -keep -repo=$GH

You can embed that in your travis directly.

I did not felt like it d fit a binary, but still i wanted to an extra indirection, just in case.

suntong, right, it should be documented.

[solvingj]

The script for .deb is fairly simple, but there's a second one for go-bin-rpm, and that one is much more complicated. So, when trying to follow this process, it's just another component written in another language with more considerations. For example, things will work as long as this GitHub repo is around and does not change, but you may want to change either of these scripts over time. So, whereas versioning of binaries is understood and well-handled, versioning of scripts referenced directly by their URL is a problem. Of course, this means users should really copy the create-pkg.sh to their own repos if they want to protect them from future changes in your repos. However, that's a real mess also.

Note, I agree that the script for deb is too simple to warrant a binary, and the one for RPM doesn't feel like it should be a binary either. To me it seems that the few steps for debs could just be part of the travis script. The one for the RPM would make the travis script long, but maybe it's still where it belongs. I'm not sure on that one.

[solvingj]

Also, I just noticed the setup-repository.sh scripts which are very similar and subject to the same factors.

[mh-cbon]

For example, things will work as long as this GitHub repo is around and does not change, but you may want to change either of these scripts over time. So, whereas versioning of binaries is understood and well-handled, versioning of scripts referenced directly by their URL is a problem.

chicken and eggs problem.

To be able to dld a constrained version of the same script as a program, you need a program, which itself should have a version the user can rely on,
so to get the program that needs the program you already need the program.

It could be a wget, like i did here, but then you are stuck on a specific version.
It could be a go get, but then forget about versions.

I hope that clarifies the matter here.

[mh-cbon]

closing this, many scripts as such are now deprecated in favor of bintrays.

this simplifies a lot of complexities.

the existing remains so current scripts don t break (i hope so, tried so), but i added some messages to clearly states the deprecation.