Are you afraid of dependencies?

Are you afraid of dependencies?

02cd14759ba3327f68f737131947781f?s=128

Glen Mailer

July 20, 2017
Tweet

Transcript

  1. Are you afraid of dependencies? Glen Mailer @glenathan

  2. “This module has no dependencies”

  3. Scared

  4. #1 Small scope no dependencies needed

  5. #2 Afraid of dependencies Author wanted to have written everything

    themselves
  6. #3 Afraid of dependency problems Author has fallen into dependency

    hell in the past
  7. Rando on HN https://news.ycombinator.com/item?id=10571452 “This is why developers should try

    to avoid introducing dependencies. Not at all costs, of course, but typical project in JavaScript, Go, Ruby, or Python has way, way too many dependencies, while little of them have any significant benefit.”
  8. Prominent Clojure community member “The ideal number of dependencies for

    a library release (not counting Clojure itself) is zero. Obviously, use common sense. If your library relies on critical functionality in another library, then make the dependency. But if you can get by without the dependency (even if that means copying some of those "utility" functions into your own code and making them private) then you will make life easier for consumers of your library.”
  9. What is a dependency anyway?

  10. #1 Module Loading How to load a dependency into the

    system
  11. #2 Package Management How to add a dependency into a

    project
  12. Commonalities between package managers

  13. Manifest of things to depend on A version for each

    thing Download from some central location Will pull in dependencies-of-dependencies aka transitive dependencies Arrange artifacts suitably for runtime module loading
  14. SemVer.org break.feature.fix

  15. Annex https://www.youtube.com/watch?v=JjYAnBhF2JU A fact-based dependency system

  16. Variations
 between package managers

  17. Global v Local Test v Dev v Real Package/Import symmetry

    Vendoring Snapshots Ranges Lockfiles Do Applications need versions? X Replaces Y (props to PHP's composer)
  18. Global v Local

  19. Dependency Hell

  20. A B@1 D@1 C@1 D@2

  21. Pick a version of D for you 1. Your app

    might work 2. copy-paste from C 3. upgrade B to work with D@2 4. don’t use C, write your own thing
  22. Tell you it can’t resolve 1. Tell it you know

    best 2. copy-paste from C 3. upgrade B to work with D@2 4. don’t use C, write your own thing :pedantic? :abort
  23. Allow D@1 and D@2 to co-exist

  24. Basically everyone “OMG that can’t possibly work!?1!”

  25. Nix Cargo

  26. Allow both to co-exist 1. Your app might work 2.

    copy-paste from C 3. upgrade B to work with D@2 4. don’t use C, write your own thing
  27. Allow co-existence What could go wrong?

  28. More bytes

  29. Type conflicts from transitive dependencies

  30. Rust: forces a re-export JS: mostly duck types

  31. Is this actually a problem?

  32. The Language of the System Hickey 2012 “Try to avoid

    bespoke protocols and formats”
  33. Allow co-existence What could go right?

  34. Less time spent keeping up Lowered cost of creating dependencies

    Smaller dependencies Less reasons
 to change Less changes
  35. None
  36. Can we add this function into core?

  37. Single function dependencies?

  38. (map-values f m) [handy/map-values "1.0.0"]

  39. Other Downsides

  40. Discovery Evaluation

  41. Is this doable in Clojure?

  42. github.com/ aav/clojure.osgi jafingerhut/dolly benedekfazekas/mranderson technomancy/metaverse

  43. In Summary

  44. The current state of dependency management has room for improvement

  45. Seek out and explore alternative approaches

  46. Don’t dismiss alternatives based only on existing experiences

  47. Thanks http://j.mp/afraid-of-dependencies