Vendorificator
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 90 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/40339 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 20132 / 90
2
5
8
10
12
13
14
15
17
19
21
24
25
28
29
31
32
34
36
39
40
43
44
46
50
51
52
54
55
57
58
62
65
66
67
78
79
87
88
00:00
Multiplication signPoint (geometry)Demo (music)Utility softwareRevision controlLecture/Conference
00:22
TrailCodeRepository (publishing)Repository (publishing)Source codeLine (geometry)Point (geometry)View (database)AuthorizationReplication (computing)Projective planeComputer animation
01:06
MathematicsRevision controlTrailSource codeLecture/Conference
01:22
Module (mathematics)SynchronizationDuality (mathematics)Finite element methodRevision controlHill differential equationBlock (periodic table)SynchronizationSource codeMathematicsBranch (computer science)Flow separationLogic gateScripting languageComputer fileModule (mathematics)Electronic mailing listRepository (publishing)Projective planeBitDemo (music)Presentation of a groupDifferent (Kate Ryan album)Theory of everythingDirectory serviceConfiguration spaceCodeRevision control1 (number)SoftwareMetadataNichtlineares GleichungssystemFigurate numberVirtualizationFunction (mathematics)Computer animation
05:25
SynchronizationEuler anglesRevision controlUniformer RaumVirtualizationDirectory serviceRevision controlSource codeBranch (computer science)Replication (computing)MathematicsDampingModule (mathematics)Computer filePoint (geometry)Function (mathematics)Different (Kate Ryan album)Computer animation
07:11
Local ringMathematicsTrailBranch (computer science)PurchasingDifferent (Kate Ryan album)Software testingLine (geometry)Open sourceLoginOcean currentDifferenz <Mathematik>Network topologyLecture/ConferenceXML
08:08
AuthorizationBranch (computer science)Module (mathematics)TrailMathematicsOpen sourceLecture/Conference
08:39
XML
08:51
Branch (computer science)Directory servicePoint (geometry)Computer fileFiber bundleCache (computing)Lecture/Conference
Transcript: English(auto-generated)
00:02
So hello, my name is Matti and I want to do a quick show and demo of a small utility that I have just open-sourced, well it is just-in-time delivery because I put the 0.1 version today. It is called vendorificator and I don't
00:23
know if you are familiar with the discussion named vendor everything. It is a point of view that if you have a project you should keep all your dependencies together in the same repository. To be independent of original author pooling the source offline, to be independent of Ruby jams break-in, to be
00:43
independent of PyPy being offline which happens way too often and so on. And you may agree or disagree or agree partially but it's worth googling the discussion. And vendorificator is a tool that works with Git to make
01:04
possible to not only include the vendor upstream sources but also make it possible to keep track of it, keep track of what pieces do you have, where they came from, in which versions and what are the local changes because there are always local changes. It works only with Git. It is written in
01:26
Ruby so it is available as a Ruby jam. It works by creating a pristine orphan brand for all the upstream modules which means that every module has its branch which is only then merged into master or whatever branch you work
01:43
on. Which also means you always have a list of modules, you always have a difference between what was originally downloaded and what you work with and so on. And if you ever go through a startup acquisition or any license compliance audit, your auditors will thank you for that. So to get started
02:09
install vendorificator jam in your Git repository and the main configuration lives in so-called vendor file or if you don't want to clutter your directory just config slash vendor Airbnb and run vendor sync to synchronize
02:27
to download. The, now the quick demo or presentation how it looks like, how it works. It's an example vendor file. It gets OBSQL traffic cookbooks. I don't want all the dependencies, just some. I want
02:45
to download virtual end for Python, some cookbooks and something for Git. It is a bit customized, it is not a simplest example but it shows that it works with various kind of upstream modules that it is extensible, it is
03:01
hackable. And let's see what can we do with that. When we try to look at we see that there are some new modules and that metadata of chef cookbooks cannot be read so it cannot figure out the dependencies. Let's try to sync
03:24
that and right now this is not a live demo because right now the vendorificator would download a lot of stuff and it takes a while but it downloads all the specified modules and their dependencies. And after that we can see
03:43
the status that everything is up-to-date including the dependencies, including the cookbooks that the ones that we specified depend on. We can see that for every module, for every downloaded piece of software,
04:02
separate branch has been created, a separate tag in Git has been created for every version of download. And we can see that the branches are orphaned. They don't inherit from master, they include only the
04:22
pristine pure upstream source which also makes it easy to merge from the pristine branches to different branches of your project without running the risk of accidentally merging in some changes of your own code. And we can
04:40
see that in vendor subdirectory all kinds of stuff has been downloaded. And I don't like the virtual-env piece. I want to edit it. I want to have only some of the files, not all of them, not all support scripts and so on, just the documentation and the main Python script. The rest is clutter. So I
05:10
call the block to edit whatever was downloaded. I also upgrade the version at dash one or whatever to let vendorificator know that it has been
05:23
changed. And in the status output we can see it is this one is outdated. When we sync, the outdated module is downloaded. It is always, if vendorificator
05:44
downloads something, it is always downloaded from scratch into an empty directory. No incremental downloads, no assuming that everything is the same. To be sure that what was downloaded is clean original upstream source. It has been downloaded, unpacked, tagged as previously. And we can see that
06:09
there are less files. I didn't put the tags in screenshot, but a new tag also has been created there. And in the log we can see that the
06:26
change was introduced into the pristine branch with a new tag and merged again into master. So all the changes in modules, all the upgrades, all the updates work on the same pristine branch, which means if you update a
06:42
dependency, go from virtualenv 1.8 to 1.9 when it is released, you also have a clear difference of what happened between the previous version you used and the current version. And if you introduced any local changes, pulling a new version is nothing more than a git merge. If you have conflicts,
07:08
you will have to resolve it, but I don't think it gets any easier. And vendorificator also supports keeping track of local changes. For a test,
07:20
I have changed, introduced a single line change, a single command, and I can run vendor diff and it shows me a git diff, a git difference for all the branches that have any changes between current work tree and the pristine
07:41
branch. I can see what exactly I have changed, how exactly I have diverged from upstream. I can view the same as a git log of changes that are on my branch but are not on the pristine branch. And this is also good to review and keep track of your local updates, of your local patches, of
08:05
what can be, I don't know if you work with open source, some of the changes you may want sometimes to push to the original author to give back to open source. If you work on a single branch, you won't keep track of it. It will be
08:23
hard to untangle. This way, you keep all the changes, and you also stay accountable to whoever reviews if you're okay with the license of the module or not. So that would be it. Now is the five minutes for questions, I
08:44
suppose, and are there any? The question was how it works with gemfile.
09:07
Actually, to be honest, I don't use it with gems. For this, if I want to vendor, I use bundle cache for gemfile, and I don't think it could be integrated. On the other hand, if you want to have some really custom gem,
09:26
for example, you copy it from git, from an unreleased branch, and then on top of it add your own modifications, you can just add it to vendor file, have it in directory, and point gemfile to that directory. This will, this should also
09:40
work. Okay, I guess that's it then. Thank you.