• Like
Introducing adept
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Introducing adept

  • 1,174 views
Published

Slides for Introducing Adept @ scala exchange 2013 …

Slides for Introducing Adept @ scala exchange 2013
Fredrik Ekholdt

Dependency management should be something nobody should need to relate to, yet a surprising amount of time is spent on this aspect which should simply work. Adept is a new dependency management system in Scala, here to change the way it is done on the JVM. This talk will be about what Adept is, why you should care and how you can help.

Published in Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,174
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Dependency managers “a dependency manager automates the process of using and upgrading software libraries in a consistent manner.” Finds the libraries you need, based on the libraries you want
  • 2. A note on dependency management It does not have any intrinsic value But saves some time/effort It is not interesting (boring) But sometime takes time (especially debugging) Useful because it shares a decision you made ʹI want lib A version 2ʹ We should update our libraries more often! So it should be easy to do
  • 3. Dependency managmenet ‑ the afghan war of the JVM?
  • 4. Introducing Adept “a person who is skilled or proficient at something.” A dependency manager Reliable Fast Knows what works with what Only a dependency manager, nothing else Platform independent
  • 5. State = identity(time,value) Identity: the library and the artifacts to be used (jars in junit, spring, ...) Value: the version to use (4.11, 3.2.5, ...) Time: the library as it is ʹright nowʹ (lib A 5.0‑SNAPSHOT today VS tomorrow) State: the version of a library at a given time
  • 6. Reliability Same result every time On the JVM, dependency managers are sort of reliable Will state (the versions of the libraries at any given time) never change?
  • 7. Versioned meta‑data Meta‑data: defines the data (dependencies, names, ...) We want: Immutable meta‑data That is easy to change Atomically change the entire meta‑data In other words: Git
  • 8. Distributed repositories Download all meta‑data for each repository Benefits You are in control of changes (pull) You can go back in time (checkout) Speed Git is supringsly good at compressing Maven central: 150 mbs of compressed data (once) No round trips to fetch meta‑data No ʹinvalidʹ meta‑data cache Parellel download of artifacts
  • 9. Artifacts and meta‑data Artifacts: represents the actual files used (jars) When you want some libraries... ..the dependency manager looks up the meta‑data Dependency manager finds the libraries you need... ...based on the meta‑data The artifacts you must download are therefore... ...defined in the meta‑data ‑ RIGHT?
  • 10. Artifacts ‑ mark 1 WRONG: Choosing a library in Ivy/Maven Means a new lookup to some repository (or cache) Artifact = file that matches the same repository pattern (or cache) Artifacts that can be chosen are: The ones supposed to be used based on some repository meta‑data The ones that happens to cached A new artifact, but using cached meta‑data A cached artifact, but using new meta‑data
  • 11. Artifacts ‑ mark 2 Cleanly seperated from meta‑data and repository Meta‑data points to the SHA‑256s Artifact lookup files: SHA‑256 and locations This means: New artifact means new meta‑data New meta‑data can safely use new/old artifact Benfits: You are sure you got the right one Easy to reason about Very easy to cache Secure
  • 12. Speed When I say ʹa8dac15ʹ... ... I do not care where it comes from Means I can: Use url to download jar from file server (nothing new) Check cache if jar is in the cache (nothting new) Use different urls to download the same jar (in pieces) Use bittorrent to download one jar Use bittorrent to download many jars ...
  • 13. State & Adept Summary: You ask for the commit hash of... The repositories you need... And the libraries you require Which points a stable set of SHA‑256 No changes in state: For a given input, same artifacts every time QED: Adept is reliable
  • 14. So... {Performance, reliabilty} does it really matter? Why hasnʹt this been fixed before?
  • 15. A killer feature?
  • 16. Compatibility matrix Dependencies maps to a compatibility matrix
  • 17. Ivy/Maven Automatically resolves to the ʹhighestʹ/ʹlatestʹ/... version Compatiblity is not factored in There is no... matrix Users must know how libraries work together: Must specify version(s) (ranges) on how libraries are compatible Override/exclude if there is a problem Programs are good at this Dos not communicate intent
  • 18. Authors declares how their libraries are compatible
  • 19. Example: sbt plugins Imagine if sbt: In addition to ʹversionʹ (0.12.0, 0.12.1, ...) Defines an extra attribute: ʹbinary‑versionʹ (0.12, ...) A plugin (e.g. sbteclipse) that requires sbt specifies the ʹbinary‑versionʹ stcis vrin10rqie stbnr-eso 01 belpe eso . eurs b iayvrin .2 stcis vrin11rqie stbnr-eso 01 belpe eso . eurs b iayvrin .2 stcis vrin20rqie stbnr-eso 01 belpe eso . eurs b iayvrin .3 The user/build tool: I use/am sbt 0.12.0, what are the sbteclipse versions I can use (Then chose the ʹbestʹ version)
  • 20. Attributes Adept allows resolution based on: version binary‑version But also: Snapshot/prerelease QA department ʹseal of approvalʹ ... Any attribute is a first‑class citizen
  • 21. Adept values Ivy/Maven: ʹversionʹ is the ʹvalueʹ of the library Adept: ʹversionʹ is a common attribute Variant == value in Adept Example: sbt { version 0.12.0, binary‑version 0.12, qa‑tested false } sbt { version 0.12.0, binary‑version 0.12, qa‑tested true }
  • 22. Variants Id com.typesafe.play/play Artifacts Attributes ʹversion = 2.2.0ʹ ʹbinary‑version = 2.2ʹ ... Dependencies Id com.typesafe.akka/akka‑actors Constraints ʹbinary‑version = 2.2ʹ ...
  • 23. Adept resolution 3 states Resolved (only one variant for each library) Under‑constrained (too many variants) Over‑constrained (conflicts, or non‑existing Id) Naive algorithm Grab Ids of dependencies ... ...and all constraints for Id ...for each resolved: repeat...
  • 24. Resolved Variants: saalbay{..,21.,21.} cl-irr 293 .02 .03 ak 205dpnso saa293 ka .. eed n cl .. ak 220dpnso saa21 ka .. eed n cl .0 ak 221dpnso saa21 ka .. eed n cl .0 pa 220dpnso {ka22 saa21} ly .. eed n ak ., cl .0 pa 221dpnso {ka22 saa21} ly .. eed n ak ., cl .0 Dependencies: play 2.2.1 + akka 2.2.0 + scala‑library 2.10.3
  • 25. Over‑constrained Variants: saalbay{..,21.,21.} cl-irr 293 .02 .03 ak 205dpnso saa293 ka .. eed n cl .. ak 220dpnso saa21 ka .. eed n cl .0 ak 221dpnso saa21 ka .. eed n cl .0 pa 220dpnso {ka22 saa21} ly .. eed n ak ., cl .0 pa 221dpnso {ka22 saa21} ly .. eed n ak ., cl .0 Dependencies: play 2.2.1 + akka 2.2.0 + scala‑library 2.9.3 Or: foobar 2.2.1 + akka 2.2.0 + scala‑library 2.10.3
  • 26. Under‑constrained??? Variants: saalbay{..,21.,21.} cl-irr 293 .02 .03 ak 205dpnso saa293 ka .. eed n cl .. ak 220dpnso saa21 ka .. eed n cl .0 ak 221dpnso saa21 ka .. eed n cl .0 pa 220dpnso {ka22 saa21} ly .. eed n ak ., cl .0 pa 221dpnso {ka223 saa21} ly .. eed n ak .., cl .0 !!^!! ! ! Dependencies: akka 2.2.3 + scala‑library 2.10.3 + play (any version) Resolves: there is only exactly one possible play version: 2.2.1
  • 27. Under‑constrained Variants: saalbay{..,21.,21.} cl-irr 293 .02 .03 ak 205dpnso saa293 ka .. eed n cl .. ak 220dpnso saa21 ka .. eed n cl .0 ak 221dpnso saa21 ka .. eed n cl .0 pa 220dpnso {ka22 saa21} ly .. eed n ak ., cl .0 pa 221dpnso {ka22 saa21} ly .. eed n ak ., cl .0 Dependencies: akka 2.2.1 + play 2.2.1 + any 2.10 scala‑library? Or: akka 2.2.1 + scala‑library 2.10.3 + any 2.2 play?
  • 28. Architecture: Extensions Adept does not do much! Ideal: I declare only binary‑versions and commit, Build tools gives me the ʹhighestʹ versions compatible Build tools needs Adept + some extensions Small core = minimal changes Different extensions, but consistent resolution
  • 29. Extensions: Conventions/attribute names and meaning Version, binary‑version Version ordering Overrides Exclusions Imports (Ivy/Maven/...) ...
  • 30. Overrides/exclusions Need to resolve ʹbenignʹ conflicts  (Versions differ, but not binary‑versions) Creates a new variant with: Different dependencies Unique ʹoverridesʹ/ʹexcludesʹ attributes The social dependency manager? I can figure how my library is used
  • 31. Other usecases Snapshots #1 Use ʹprereleaseʹ/ʹsnapshotʹ/... attribute Overwrite variant + commit new version Update meta‑data = new snapshot Flexible ... ...but you know exactly which artifact/meta‑data that was used
  • 32. Other usecases Snapshots #2 CI & nightlies: We know which version we used: Safely update metadata after passing tests User use same constraints (even when stable is released) But build tool can give warning No SNAPSHOTs after a release, and... ...no failures because a ʹversionʹ has been removed
  • 33. Where are we at?
  • 34. What works Resolution ʹEqualityʹ constraint binary‑version 1.0 == 1.0 Extensions: Overrides, excludes Version ordering Ivy imports Tests (test framework)
  • 35. Help! Final design! Now is the time to set things straight Handle libraries that defines the same interface Attribute types & comparable constraints? (types, !=, >, <, ...) Meta‑data is not (de)serialized Artifacts files are not (de)serialized More tests/use cases
  • 36. Help!! Git is not implemented No CLI (useful for testing) No built tool plugins (we need: sbt, gradle, SBuild, ant, maven?) Resolution is concise (but could even more concise?) Resolution is fast (but could be faster?)
  • 37. In other words: We NEED you!
  • 38. Exciting stuff because We can get it right this time!
  • 39. But... We have to build a new ecosystem :(
  • 40. Adepthub
  • 41. Ideal workflow 1.  Figure the library you want 2.  Choose only version(s) you want to be compatible with 3.  Repeat
  • 42. Adepthub #1 Online resolution using Adept Hosts meta‑data Workflow: 1.  Go to adepthub.com 2.  Search and add new (compatible) libraries 3.  Save (creates a perma link) 4.  User/plugin/build tool downloads one file with: Perma link, if you want to update Locations (urls) and some human readable meta‑data for all artifacts
  • 43. Adepthub benefits For you: Uses Adept and hosts Adept repositories Search across all repositories using: Keywords on Id Project info: github url, author, company, ... No need to download meta‑data However, it is possible to do it if you want Import (meta‑data enhancement) Resolution is done online... ...but can be consumed by maven, ivy, ... = no plugins required
  • 44. Adepthub benefits For library authors: Easy to publish Github interface Public & private repositories Can have nice stats: Who is using version X anyways? Now we know! Trophies: show your awesomeness For me: Easier to build plugins Read file + download artifacts Launches: When it is done, hopefully February/March
  • 45. Feedback Is search.maven.org good enough? Please show support by signing up for beta: http://adepthub.com/#beta
  • 46. Interested? https://github.com/adept‑dm/adept  (README links to: mailing list/spec)
  • 47. Thanks freekh+adept ʹatʹ gmail.com @ekhfre