Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove old golang dependencies #2795

Open
10 of 21 tasks
nitrocode opened this issue Dec 14, 2022 · 4 comments
Open
10 of 21 tasks

Remove old golang dependencies #2795

nitrocode opened this issue Dec 14, 2022 · 4 comments
Labels
feature New functionality/enhancement help wanted Good feature for contributors security

Comments

@nitrocode
Copy link
Member

nitrocode commented Dec 14, 2022

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Describe the user story

There are a lot of dependencies that may not be needed. Some dependencies are years old and could be vulnerable. The fewer dependencies, the less risk.

Describe the solution you'd like

It would be good to audit our dependencies and find ones that could be easily replaced or removed. We should use non forks if possible unless there is a good reason to use a fork.

It would also be good to scrutinize new PRs with additional dependencies to ensure we do not unnecessarily increase our exposure. For example, we should never use a dependency that is a fork or archived, possibly abandoned, not widely used, has old dependencies, or open security issues.

List of current dependencies https://github.com/runatlantis/atlantis/network/dependencies

Some old dependencies from a cursory look

Analyzing these will simplify dependent management via renovatebots dashboard #2818

Direct

archived

archived no longer

old

For testing

These do not get compiled with Atlantis

Indirect

These come from other dependencies and need to be analyzed to find the direct source

https://stackoverflow.com/a/68927825/2965993

Some tools that may be useful

Here are all the go.mod code references sorted in ascending order

✗ grep -v indirect go.mod | grep -v ^module | grep github.com | awk '{ print $1 }' | sort | uniq | while read dep; do echo $(grep -r $dep **/*.go | wc -l):$dep; done | sort -n
1:github.com/Masterminds/sprig/v3
1:github.com/agext/levenshtein
1:github.com/alicebob/miniredis/v2
1:github.com/bradleyfalzon/ghinstallation/v2
1:github.com/briandowns/spinner
1:github.com/cactus/go-statsd-client/v5
1:github.com/go-test/deep
1:github.com/golang-jwt/jwt/v5
1:github.com/hashicorp/go-getter/v2
1:github.com/kr/pretty
1:github.com/microcosm-cc/bluemonday
1:github.com/mitchellh/colorstring
1:github.com/redis/go-redis/v9
1:github.com/remeh/sizedwaitgroup
1:github.com/spf13/pflag
1:github.com/warrensbox/terraform-switcher
2:github.com/google/shlex
2:github.com/hashicorp/terraform-config-inspect
2:github.com/mohae/deepcopy
2:github.com/shurcooL/githubv4
2:github.com/urfave/negroni/v3
3:github.com/gorilla/websocket
3:github.com/hashicorp/go-multierror
3:github.com/hashicorp/hcl/v2
3:github.com/moby/patternmatcher
3:github.com/spf13/viper
4:github.com/go-playground/validator/v10
4:github.com/mitchellh/go-homedir
5:github.com/google/uuid
5:github.com/spf13/cobra
6:github.com/slack-go/slack
7:github.com/gorilla/mux
13:github.com/mcdafydd/go-azuredevops
13:github.com/stretchr/testify
14:github.com/xanzy/go-gitlab
16:github.com/go-ozzo/ozzo-validation
23:github.com/uber-go/tally/v4
26:github.com/google/go-github/v53
53:github.com/pkg/errors
60:github.com/hashicorp/go-version
227:github.com/petergtz/pegomock/v3

Describe the drawbacks of your solution

Potential breakage of the app unless proper unit and integration test coverage is there.

Describe alternatives you've considered

None

@nitrocode nitrocode added feature New functionality/enhancement security labels Dec 14, 2022
@chenrui333
Copy link
Member

This is very nice!!

@nitrocode nitrocode pinned this issue Dec 20, 2022
@nitrocode nitrocode changed the title Remove old dependencies Remove old golang dependencies Dec 29, 2022
@nitrocode nitrocode unpinned this issue Mar 30, 2023
@nitrocode nitrocode pinned this issue Apr 10, 2023
@nitrocode nitrocode unpinned this issue Aug 26, 2023
@mitar
Copy link

mitar commented Oct 9, 2023

Shameless plug: as an alternative to https://github.com/pkg/errors, you can switch to drop-in replacement gitlab.com/tozd/go/errors. It fixes many issues, is maintained, and supports modern Go's error patterns (sentinel errors, %w formatting, joined errors, etc.). It also provides some nice utility functions and structured details so that it is easy to extract dynamic data out of errors (instead of trying to get them out of formatted strings). Has improved error formatting and JSON marshaling of errors. It is interoperable with other errors packages and does not require a dependency on itself to extract data (e.g., stack trace) from errors.

@nitrocode
Copy link
Member Author

@mitar what about just the errors package? How does it compare?

I'm hesitant to push this project to replace an archived dependency for one that's uncommonly used (judging by project stars)

@mitar
Copy link

mitar commented Nov 5, 2023

@nitrocode I completely understand. But it is a bit of chicken & egg problem. :-)

I think the questions for you is if you need/want stack traces or not. If you do, then this package provides almost the same API as the standard errors package, but with stack traces (see here for details). Also using this package and in the future (hopefully once stdlib gets stack traces) moving to errors should also be easy as my package provides compatible API. Of course, if you find additional helper functions it provides as well, for common patterns, useful, then you can use them as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement help wanted Good feature for contributors security
Projects
None yet
Development

No branches or pull requests

3 participants