Not sure how useful this package is, *but* I'm packaging everything I have now,
and then in a separate CL I can refactor and remove various libs.
Change-Id: Id106539b19244ea1586198992c7ce0d65a0a242b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6014
Reviewed-by: wpcarro <wpcarro@gmail.com>
Autosubmit: wpcarro <wpcarro@gmail.com>
Tested-by: BuildkiteCI
More fixes along the way
Change-Id: I6b62eb0545981c2792d6c70089fe81324ba2dbf0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6010
Reviewed-by: wpcarro <wpcarro@gmail.com>
Autosubmit: wpcarro <wpcarro@gmail.com>
Tested-by: BuildkiteCI
Attempting to use `depot.tools.releases.filteredGitPush` for the first
time. Exciting!
Change-Id: I620140b0454128ea2ca51496a7d653ee4219104e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6006
Reviewed-by: wpcarro <wpcarro@gmail.com>
Autosubmit: wpcarro <wpcarro@gmail.com>
Tested-by: BuildkiteCI
This will likely break a few things since I've changed the names of a few
functions to reflect their mutative APIs.
Change-Id: If6279999fba50813b68e66d7713c12afd209eb90
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6004
Reviewed-by: wpcarro <wpcarro@gmail.com>
Autosubmit: wpcarro <wpcarro@gmail.com>
Tested-by: BuildkiteCI
I was getting false-positive ERT test results because I forgot to use the
`should` macro in my assertions. I discovered this when debugging a subtle bug
in cycle.el that depends on `list-contains?` return `t` or `nil` instead of
truthy or falsy values.
Change-Id: Ibbf89fd1c4f50f86d5efcaa4cd87280b97e111ce
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6003
Reviewed-by: wpcarro <wpcarro@gmail.com>
Autosubmit: wpcarro <wpcarro@gmail.com>
Tested-by: BuildkiteCI
Mostly just a wrapper around s.el (for now?). Eventually I'd like to prune the
dependency on dash.el (and maybe s.el).
Change-Id: I5c2ba256524bedd93fcd13933fdbd95b1ddff6f8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6002
Reviewed-by: wpcarro <wpcarro@gmail.com>
Autosubmit: wpcarro <wpcarro@gmail.com>
Tested-by: BuildkiteCI
Originally I set-out to package `al.el`, but as I started traversing the
dependencies, I needed to package increasingly more packages. I refactored some
of these to prune their dependencies to slay this hydra before it turned into a
never-ending project. I have mixed feelings about this.
I also introduced `ert` and unit tests into my Elisp packaging, so it'll be nice
to have build-time tests that run when Emacs updates land in depot.
Change-Id: I2756dc60888b80255a495e08ae61bd547e6b3db2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5998
Reviewed-by: wpcarro <wpcarro@gmail.com>
Autosubmit: wpcarro <wpcarro@gmail.com>
Tested-by: BuildkiteCI
The end-goal is to package all of my Elisp libraries. Why?
- More granular builds/tests
- More explicitly defined dependencies
- Separate personal configuration from library code
- Ease distribution
Change-Id: I2507d129d3a0b3bf0cfe70b9790536a8b2093b96
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5969
Tested-by: BuildkiteCI
Reviewed-by: wpcarro <wpcarro@gmail.com>
Autosubmit: wpcarro <wpcarro@gmail.com>