As a developer I would like to settle on a distribution model #43

New Issue

sloum · 2019-10-01T04:05:03Z

sloum commented

2019-10-01 04:05:03 +00:00

Depending on systems we want to support our options are many:

Linux: DEB/RPM (via APT, YUM, Etc), Appimage, Flatpack, Snap Pack, Source build via makefile, just a git link, prebuilt binaries for various architechtures
OSX: Homebrew, Macports, Source build w/ makefile, just a git link, prebuild binaries
BSD: I have no clue, not enough experience with the system. I'll look into it.
Plan 9: Not officially supported
Windows: Likely no support for windows command line, linux subsystem might work, but I dont know much about it

After a ton of reading I am leaning toward just distributing via git link and a makefile in the root dir. It seems like it works fine and suits the intended audience fine... though the many many other options also have upsides. This issue was created to see if there is consensus on route forward for v2.0.0 release, and if not discuss pros/cons/options.

Depending on systems we want to support our options are many: - **Linux**: DEB/RPM (via APT, YUM, Etc), Appimage, Flatpack, Snap Pack, Source build via makefile, just a git link, prebuilt binaries for various architechtures - **OSX**: Homebrew, Macports, Source build w/ makefile, just a git link, prebuild binaries - **BSD**: I have no clue, not enough experience with the system. I'll look into it. - **Plan 9**: Not officially supported - **Windows**: Likely no support for windows command line, linux subsystem might work, but I dont know much about it After a ton of reading I am leaning toward just distributing via git link and a makefile in the root dir. It seems like it works fine and suits the intended audience fine... though the many many other options also have upsides. This issue was created to see if there is consensus on route forward for v2.0.0 release, and if not discuss pros/cons/options.

sloum added the

non-code

label 2019-10-01 04:05:23 +00:00

asdf commented

2019-10-02 02:11:33 +00:00

I used a makefile for gfu as it seems like the minimum barrier for distributing software, but it relies on having the appropriate software for building installed locally. This would likely be ok for the intended audience.

Other packaging options would be useful not just for ease of installation, but it would also expose new people to bombadillo when they see it in the repository. For example, if a snap was built and made available through the snap store. This means some new learning/effort, for every package type used.

With all this said, I don't install bombadillo often. What would a sysop prefer?

I used a makefile for gfu as it seems like the minimum barrier for distributing software, but it relies on having the appropriate software for building installed locally. This would likely be ok for the intended audience. Other packaging options would be useful not just for ease of installation, but it would also expose new people to bombadillo when they see it in the repository. For example, if a snap was built and made available through the snap store. This means some new learning/effort, for every package type used. With all this said, I don't install bombadillo often. What would a sysop prefer?

sloum commented

2019-10-02 19:46:04 +00:00

Yeah, I am mostly inclined to go the makefile route. I may make a developer makefile as well that can build binaries for all supported platforms so that binaries can be offered at least for major versions (not sure I want to deal with upkeep of binaries for minor versions).

asdf commented

2019-10-11 04:00:38 +00:00

I asked @cmccabe about this a little while ago, who provided some really interesting ideas on this. The main point was not so much about installing but rather in updating or even removing the software.

A makefile would probably be the first thing to do, as it's the most universal. It would still be worth doing something to help with updates - a snap might be the easiest, ending up in a repository would be the most comprehensive.

Thanks @cmccabe!

I asked @cmccabe about this a little while ago, who provided some really interesting ideas on this. The main point was not so much about installing but rather in updating or even removing the software. A makefile would probably be the first thing to do, as it's the most universal. It would still be worth doing something to help with updates - a snap might be the easiest, ending up in a repository would be the most comprehensive. Thanks @cmccabe!

ben commented

2019-10-14 17:45:29 +00:00

git pull && make install is very easy distribution method for me, preferably installing to an overridable $PREFIX that would default to /usr/local

`git pull && make install` is very easy distribution method for me, preferably installing to an overridable `$PREFIX` that would default to `/usr/local`

sloum commented

2019-10-14 18:04:23 +00:00

@ben I had not thought of the application being installed outside of $GOPATH/bin/bombadillo. If you are wanting this behavior I would imagine that there are others that would also like to be able to manage things in this way. This is definitely in scope for where we are at in the v2.0.0 release process (I am currently working on the Makefile).

I am also glad to hear that the git pull && make install method sounds good to you. I feel pretty good about it at this point as well 👍

@asdf any thoughts on any of the above from @ben?

@ben I had not thought of the application being installed outside of `$GOPATH/bin/bombadillo`. If you are wanting this behavior I would imagine that there are others that would also like to be able to manage things in this way. This is definitely in scope for where we are at in the v2.0.0 release process (I am currently working on the Makefile). I am also glad to hear that the `git pull && make install` method sounds good to you. I feel pretty good about it at this point as well :thumbsup: @asdf any thoughts on any of the above from @ben?

ben commented

2019-10-15 14:14:31 +00:00

I run tilde.team and tilde.club and would like to be able to install system-wide and not just for my own user. I ended up running go build and then just copying the executable to /usr/local/bin/. Works fine, but would be nice to have that as a supported install method.

I run tilde.team and tilde.club and would like to be able to install system-wide and not just for my own user. I ended up running `go build` and then just copying the executable to `/usr/local/bin/`. Works fine, but would be nice to have that as a supported install method.

sloum commented

2019-10-15 14:33:37 +00:00

I have a PR open for the makefile. It allows you to pass in options for both where to install and where to have the default config file, I'll have to think out how to make that default config file option work better in a multiuser environment. I'll get back to you on it. But it will definitely be able to install to any place you like :)

EDIT: I'll make it so that the compile time logic can take a ~ to represent a users directory for the CONF_PATH variable. That should make it reasonably flexible for admins to have home folders set up how they would like. Combined with the BUILD_PATH variable I think it should accomplish what you need it to.

I have a PR open for the makefile. It allows you to pass in options for both where to install and where to have the default config file, I'll have to think out how to make that default config file option work better in a multiuser environment. I'll get back to you on it. But it will definitely be able to install to any place you like :) EDIT: I'll make it so that the compile time logic can take a `~` to represent a users directory for the CONF_PATH variable. That should make it reasonably flexible for admins to have home folders set up how they would like. Combined with the BUILD_PATH variable I think it should accomplish what you need it to.

sloum commented

2019-10-23 05:37:54 +00:00

As we have firmly settled on makefile as our build/release model, I will close this card.

For reference, the makefile gets merged in by #57 and updated by #59.

As we have firmly settled on makefile as our build/release model, I will close this card. For reference, the makefile gets merged in by #57 and updated by #59.

sloum closed this issue

2019-10-23 05:37:55 +00:00

Sign in to join this conversation.