Consider Enabling Version Releases
SFDC-AaronKulick opened this issue · comments
I would like to propose that the project consider marking and cutting "releases" which would allow folks to better track the project and maintain installers (e.g. Homebrew) or at least add such formalization to the roadmap. Versioning will help folks track updates and simplify installation as well as increase adoption.
Many thanks...
-AK
The current installation instructions are simple and remove hurdles for people start creating their own commands.
That said, there is merit in maintaining a CHANGELOG and tagged versions are more readable than SHAs.
Perhaps there is a happy medium. What if user commands could be automatically picked up from from somewhere like ${XDG_DATA_HOME}/bma/?
In here you ask for arguments that a Homebrew or FreeBSD port would improve the project. I'll bite.
Historically, the argument for not having a complete wrapper for aws-cli was that the job to was too big, and nobody really needed all of it anyway. While it the project had like 50 stars, I agreed that a user-extendable tool was the right decision.
As BMA is now approaching 500 stars, I think it's time to seriously reconsider that decision. I believe that it's fair to say that the majority of users do not want to develop and create custom functions for BMA. For those users, the current installation process of forking the Git repo is excessive, and I worry is off-putting.
The project is currently organised in a way that makes it impossible to package. However the inverse of making BMA packagable does not preclude it from being forked and developed by sufficiently motivated engineers.
I believe we now have the critical mass required to make a near feature-complete wrapper for aws-cli. We should focus on getting users to later convert to contributors. We should be making it easier to get people in, even if that makes it harder for them to contribute.
I also believe that we should put less focus on it being a tool that as a user, you can easily extend. Yes, that should continue being a feature, but the goal should shift to developing a complete wrapper so that it's almost never required.
Definitely keen to remove impediments to adoption (we put a lot of work into supporting zsh users) but I don't believe the current installation instructions are too hard to follow.
I've included them below as they're core to this discussion:
They make it transparent what's happening on your system when you install this tool.
Other than the unix commands (grep, awk, etc) found on your system, there are very few dependencies - awscli, bash, jq. The bar is already very low.
Prerequisites
Installation
As shown below, you may simply clone the GitHub repo and source the files required.
(You should probably fork it instead to keep your customisations)
$ git clone https://github.com/bash-my-aws/bash-my-aws.git ~/.bash-my-awsPut the following in your shell's startup file:
export PATH="$PATH:$HOME/.bash-my-aws/bin"
source ~/.bash-my-aws/aliases
# For ZSH users, uncomment the following two lines:
# autoload -U +X compinit && compinit
# autoload -U +X bashcompinit && bashcompinit
source ~/.bash-my-aws/bash_completion.shWhile I like the idea of a simple system for plugins, I don't want to try to support anything near the current number of services AWS offers in the core project.
AWSCLI Services supported 6 Jan 2020
- accessanalyzer
- acm
- acm-pca
- alexaforbusiness
- amplify
- apigateway
- apigatewaymanagementapi
- apigatewayv2
- appconfig
- application-autoscaling
- application-insights
- appmesh
- appstream
- appsync
- athena
- autoscaling
- autoscaling-plans
- backup
- batch
- budgets
- ce
- chime
- cloud9
- clouddirectory
- cloudformation
- cloudfront
- cloudhsm
- cloudhsmv2
- cloudsearch
- cloudsearchdomain
- cloudtrail
- cloudwatch
- codebuild
- codecommit
- codeguruprofiler
- codeguru-reviewer
- codepipeline
- codestar
- codestar-notifications
- cognito-identity
- cognito-idp
- cognito-sync
- comprehend
- comprehendmedical
- compute-optimizer
- configservice
- configure
- connect
- connectparticipant
- cur
- dataexchange
- datapipeline
- datasync
- dax
- deploy
- detective
- devicefarm
- directconnect
- discovery
- dlm
- dms
- docdb
- ds
- dynamodb
- dynamodbstreams
- ebs
- ec2
- ec2-instance-connect
- ecr
- ecs
- efs
- eks
- elasticache
- elasticbeanstalk
- elastic-inference
- elastictranscoder
- elb
- elbv2
- emr
- es
- events
- firehose
- fms
- forecast
- forecastquery
- frauddetector
- fsx
- gamelift
- glacier
- globalaccelerator
- glue
- greengrass
- groundstation
- guardduty
- health
- history
- iam
- imagebuilder
- importexport
- inspector
- iot
- iot1click-devices
- iot1click-projects
- iotanalytics
- iot-data
- iotevents
- iotevents-data
- iot-jobs-data
- iotsecuretunneling
- iotthingsgraph
- kafka
- kendra
- kinesis
- kinesisanalytics
- kinesisanalyticsv2
- kinesisvideo
- kinesis-video-archived-media
- kinesis-video-media
- kinesis-video-signaling
- kms
- lakeformation
- lambda
- lex-models
- lex-runtime
- license-manager
- lightsail
- logs
- machinelearning
- macie
- managedblockchain
- marketplace-catalog
- marketplacecommerceanalytics
- marketplace-entitlement
- mediaconnect
- mediaconvert
- medialive
- mediapackage
- mediapackage-vod
- mediastore
- mediastore-data
- mediatailor
- meteringmarketplace
- mgh
- migrationhub-config
- mobile
- mq
- mturk
- neptune
- networkmanager
- opsworks
- opsworks-cm
- organizations
- outposts
- personalize
- personalize-events
- personalize-runtime
- pi
- pinpoint
- pinpoint-email
- pinpoint-sms-voice
- polly
- pricing
- qldb
- qldb-session
- quicksight
- ram
- rds
- rds-data
- redshift
- rekognition
- resource-groups
- resourcegroupstaggingapi
- robomaker
- route53
- route53domains
- route53resolver
- s3
- s3api
- s3control
- sagemaker
- sagemaker-a2i-runtime
- sagemaker-runtime
- savingsplans
- schemas
- sdb
- secretsmanager
- securityhub
- serverlessrepo
- servicecatalog
- servicediscovery
- service-quotas
- ses
- sesv2
- shield
- signer
- sms
- snowball
- sns
- sqs
- ssm
- sso
- sso-oidc
- stepfunctions
- storagegateway
- sts
- support
- swf
- textract
- transcribe
- transfer
- translate
- waf
- waf-regional
- wafv2
- workdocs
- worklink
- workmail
- workmailmessageflow
- workspaces
- xray
I suppose I'm making two arguments.
- It should be installable with package manager
- It should be a complete complete wrapper.
I'm going to drop argument 2 as it is unrelated to the issue at hand and expand argument 1.
To enable maintainers to package BMA for distribution has many pros for the user.
-
Dependency Management provided by the system. Sure, it just has a single dependency, but it's still one less thing to consider.
-
Special steps are not required upgrade to latest code. You upgrade your system, and you get the latest BMA.
-
It removes the requirement of Git, and how to use it, and substitutes in the requirement that the user know how to use their systems package manager.
-
The current installation method can still be supported -- even endorsed if you wanted to.
-
In this instance, providing choice can only encourage adoption, and it comes at a pretty low cost; tagging releases for third-parties to create and distribute packages for the various platforms.
There is just one con for developers that I can think of; care needs to be taken around breaking changes, but semantic versioning can help manage that.
(at this point I'm basically parroting the OP, but a thought out response must count for more than a 👍).
I suppose I'm making two arguments.
1. It should be installable with package manager
I'm open to tagging releases and maintaining a CHANGELOG.
I'd welcome a PR with scripts to assist with that process.
Regarding priority for package managers, it's not currently a high priority for this project. (This could change of course).
I feel that for this project, including it in package managers could make marginally things easier for users but not simpler. It's a lot more effort learn how to audit third party packages than view existing installation instructions.
Yesterday when trying to install Signal Desktop on Fedora I came across this comment from their dev team:
@justinkterry Realistically, with limited resources—two people full-time on desktop app—there are other features that have higher priority and officially supporting more platforms might also introduce extra support needs which we might not be able to meet to people’s satisfaction with the current team size.
We’d appreciate community help on improving the documentation on how to install the app from source for people on non-Debian systems in the meantime. Hopefully, as we grow our team, we can make the app more easily available on more platforms.
Now, SignalDesktop has packages in FlatPak, Snap, etc but who knows who's maintaining them? From a security and transparency viewpoint, I'd rather for getting my code from the source (Signal) or a trusted packager (Fedora) than an untrusted third party.
I appreciate all the feedback this suggestion has received and I just wanted to clarify that I am not suggesting that developers take over the package generation responsibilities in addition to development. I do acknowledge it would require some effort to formalize on a release tagging process which is why I suggested it as a roadmap item if there are no other more pressing priorities. Adoption of a release tag is not a barrier for my use of BMA and was not intended as a criticism of BMA in any way. Instead, I put the suggestion forward because I believe BMA could find a wider audience who would benefit from exposure (I often conduct searches like brew search aws or brew search bash to help me discover new utilities).
I also want to be clear, I do not think that the current installation is difficult or even complicated, but I do agree with the comment/observation by that there are large number of folks who would use BMA without further modification and Homebrew often makes some utilities a "no-brainer" for a lot of folks. It is my belief that a application of a release tag does not require a re-organization of the existing code or a plug-in structure to support and that once a process established relatively self-sustaining.
Homebrew certainly is not for everyone (not to mention platform specific, however, there is a very popular Linux variant), but speaking for myself, I find it somewhat cumbersome to remember to regularly git pull, but have (ironically or perhaps pathetically) baked brew update && brew upgrade into my regular OpSec. It is my belief that most packaging systems prefer or require "releases" and I presumed other distribution systems could benefit as well.
To address the security concerns raised by @mbailey for third party packages and their integrity, it is the very existence of the release tag and the corresponding SHA which Homebrew explicitly depends on (Homebrew formula would source the release with SHA verification). As for the responsibility and who would be maintaining the integration, it is my opinion that once initial PR for Homebrew integration is completed that at least the Homebrew integration itself would trivial to maintain for any community member even one who is not an active BMA contributor (update the forumla's BMA release tag and provide the new SHA) with the rest of the forumla effectively unchanged barring some major re-organization event in BMA itself.
I would happily volunteer to prepare the PRs for Homebrew integration (including the relevant documentation for adding "private" extensions of BMA without them being clobbered by the Homebrew package on update). I would further volunteer to prepare a script/tool to prepare an updated Homebrew formula which could be potentially incorporated as part of a release pipeline process.
I want to be very clear, however, that even if BMA were to adopt release tags and a PR for a formula were submitted for Homebrew, there is no guarantee that the Homebrew community would accept it (they could decline based on their estimation of the BMA's popularity or any other myriad number of reasons) but a tagged release is a requirement (it helps folks track changes and feature/fixes) and I thought I would put it to the team to consider the idea if not now, then perhaps at some convenient point in the future roadmap. If nothing else, BMA could offer a public Homebrew tap (via another repo in the org) which would conveniently a curated upstream for a Homebrew formula.
Like I said, I thought I would float the idea and see what folks thought about it.
Perhaps it is not yet time and I do not wish to appear at all ungrateful if the suggestion is shelved for now because I have extracted a significant amount of utility from BMA and believe others could do so as well. Thank you.
I would happily volunteer to prepare the PRs for Homebrew integration
(including the relevant documentation for adding "private" extensions of
BMA without them being clobbered by the Homebrew package on update). I
would further volunteer to prepare a script/tool to prepare an updated
Homebrew formula which could be potentially incorporated as part of a
release pipeline process.
I too would love to see BMA made available in Homebrew and am happy to offer any help I can to get it there.
My copypasta above @'d someone not related to this project who is now getting emailed each time someone posts. I couldn't work out how to stop this so I'm closing this thread and have created #265.
I'd welcome a PR with a script to assist with updating CHANGELOG and tag releases.
I have an open mind about packaging but I have more pressing priorities at this point in time (including work on my presentation for linuxconf next week).