|
i have never heard the term "vendoring" wrt source control
|
#
?
May 25, 2020 04:59
|
|
|
|
| # ? Oct 11, 2024 08:36 |
|
|
rotor posted:wait i though vendoring was a weird way millenials say "check it into version control," is that not the case? I mean, that's what I do, but some people have a moral objection to doing that so they store dependencies somewhere else maybe I'm using the wrong term? I'm saying "vendoring" to mean "saving dependencies somewhere that's not their original source"
|
|
#
?
May 25, 2020 05:06
|
|
|
pokeyman posted:I mean, that's what I do, but some people have a moral objection to doing that those people are stupid. tell them i hate them.
|
|
#
?
May 25, 2020 05:09
|
|
|
rotor says y'all are stupid and they hate you
|
|
#
?
May 25, 2020 05:24
|
|
|
also this is reminding me that xcode's swift package manager integration doesn't really allow for checking in dependencies and that sucks
|
|
#
?
May 25, 2020 05:25
|
|
|
rotor posted:wait i though vendoring was a weird way millenials say "check it into version control," is that not the case? my interpretation of "vendoring" was "make sure you have a known set of dependencies in the final artifact for your software product." artifactory and abuse of your vcs are both ways to accomplish that this is the use in a bunch of horrible p-lang products anyway -- the word comes from having a 'vendor' subdirectory in your project
|
|
#
?
May 25, 2020 05:30
|
|
|
rotor posted:wait i though vendoring was a weird way millenials say "check it into version control," is that not the case? you can also copy half the open source repo into your own private lovely 2-years-out-of-date inhouse server and then check pointers to that into source control basically your build is fine if the world falls down, but not if the company falls down
|
|
#
?
May 25, 2020 05:50
|
|
|
e: oh another page thank you for explaining vendoring
|
|
#
?
May 25, 2020 05:53
|
|
|
animist posted:you can also copy half the open source repo into your own private lovely 2-years-out-of-date inhouse server and then check pointers to that into source control So basically fork it and build from that? idk, seems fine if you need to alter it but a lot of hassle if you don't.
|
|
#
?
May 25, 2020 06:10
|
|
|
i just download the jars or npm modules or whatever and dump them in /lib and commit em to git and call it a fuckin day, y'all doin it the hard way imo
|
|
#
?
May 25, 2020 06:11
|
|
|
sometimes when you build software you have third-party libraries you must use. oftentimes they are closed-source. when you have more than a couple, it's a common pattern to use a vendor directory - you got this from a vendor (say, a library one of the POS terminals you support or w/e). normally you'll only bother with this if the vendor released actual source instead of a package with headers and libraries to link against - it's what you do when both you and the vendor are too lazy to actually package the library. the similarity to third-party open source code is obvious, so people started shoving those in the vendor dir as well. when web dev communities (particularly ruby and javascript in my experience, but maybe others too) were repeating the past 20 years of lessons learned from java, they (finally) figured out that downloading everything from GitHub was bad, but didn't have the infrastructural knowledge to set up a caching proxy (and they certainly couldn't afford actual enterprise artifact management). so they "vendored" everything. better than having a build dependency on GitHub I guess, but far from ideal. but yeah, it's silly to vendor all your dependencies, because they should be in a separate service that serves your whole org, not just one repository. for personal stuff you're making public, it makes sense if you can reasonably expect people to not have whatever esoteric library you're using and want them to be able to just "make" instead of installing weird rear end dependencies from random people's package repositories or w/e
|
|
#
?
May 25, 2020 07:04
|
|
|
idk man disk space is pretty cheap. I can understand poo poo like nexus for really large orgs, like 2, 3000+ devs. But for most places I have serious doubts that the extra hassle and the extra infra is worth is. Just check your poo poo into git and get on with your life. rotor fucked around with this message at 07:13 on May 25, 2020 |
|
#
?
May 25, 2020 07:08
|
|
|
Notorious b.s.d. posted:a dude itt literally suggested that committing to master is so bad and evil that filing several pull requests a day -- paperwork -- is better than just, you know, talking to your coworkers about code I understand now its foolish to engage with you but here goes. As soon as you say 'If you don't want to you can just commit to master directly' then that becomes the only process because people are vain and arrogant and won't follow a process with even a single more step if they don't have to. Obviously 'they' know thier change is all fine and good, it was the other rear end in a top hat that broke it. I can almost see it in an SVN place but if you're using GIT is essentially negligent to not use PRs to wrap up your changes. Also if you're PR lives more than a week or so, depending on your rate of change in your codebase then you've not branched, you've forked.
|
|
#
?
May 25, 2020 08:27
|
|
|
Aramoro posted:I can almost see it in an SVN place but if you're using GIT is essentially negligent to not use PRs to wrap up your changes. there's nothing preventing you from implementing PRs in svn either, there's nothing special about git in this respect. The last time was somewhere with SVN, we did exactly that.
|
|
#
?
May 25, 2020 08:35
|
|
|
Notorious b.s.d. posted:that's exactly what your default pr merge does -- often idiots run tests in the pr branch, not the resulting branch after the merge I am going to blow your mind. You can set up your CI so it runs tests on a virtual merge commit 
|
|
#
?
May 25, 2020 08:50
|
|
|
And you can also, wait for it, require PRs to rerun pipeline if the master has moved
|
|
#
?
May 25, 2020 08:51
|
|
|
animist posted:you can also copy half the open source repo into your own private lovely 2-years-out-of-date inhouse server and then check pointers to that into source control it's actually going to be fine as long as the world doesn't fall down or have a left-pad at the same time as your lovely backup server goes down assuming your package manager either (a) supports the highly advanced concept of a fallback repository, or (b) makes it trivial to change repository URLs when needed, or (c) your ci system is able to apply an envvar url to the dependencies file
|
|
#
?
May 25, 2020 08:52
|
|
|
Xarn posted:I am going to blow your mind. i once saw a ci setup that: 1) cloned the repo 2) checked out the feature branch 3) git --hard reset to origin/master 4) merged master into the "feature branch" people were wondering why tests were failing after merging 
|
|
#
?
May 25, 2020 08:59
|
|
|
rotor posted:or just check your loving dependencies into version control and have one less pile of poo poo to maintain
|
|
#
?
May 25, 2020 09:00
|
|
|
Oneiros posted:i once saw a ci setup that: lol
|
|
#
?
May 25, 2020 09:07
|
|
|
Sagacity posted:and then manually maintain all these dependencies and poo poo up your version control history, this definitely sounds much better, yes I feel like actually having to do some vetting of your dependencies is maybe not the worst idea on earth, nor do i really see how tracking different versions of files is somehow beyond the purview of a version control system.
|
|
#
?
May 25, 2020 09:08
|
|
|
Sagacity posted:and then manually maintain all these dependencies and poo poo up your version control history, this definitely sounds much better, yes We do this because our project is old but it also doesn't seem that much of a hassle. How would you poo poo up your version control by maintaining your dependencies in there? If we want to upgrade something, like RESTEasy or something like that then it's a big deal, and given that we are required to put our software into escrow we need to have copies of those things on hand anyway.
|
|
#
?
May 25, 2020 09:11
|
|
|
presumably you are submitting some kind of change where the description is "update X dependency to version Y", whether that's a change to your copy of the dependency's code or to your lockfile or whatever. nobody's going to look at the contents of that change after-the-fact, who cares how many bytes it is?
|
|
#
?
May 25, 2020 09:23
|
|
|
Jabor posted:presumably you are submitting some kind of change where the description is "update X dependency to version Y", whether that's a change to your copy of the dependency's code or to your lockfile or whatever. at least with vendoring you have the potential of having the source changes in deps actually being reviewed. no way in hell your typical dev at your typical shop is gonna dig up the changelog for dependency update out-of-band. or maybe i've just worked at lovely places  poo poo, at this point i'd consider myself lucky to have coworkers who are even competent enough to read a change log to figure out when a bug was introduced or fixed in a dependency. <edit> basically, if you've got coworkers capable of reading and comprehending the text that is displayed on their monitors, you're in good place Oneiros fucked around with this message at 09:37 on May 25, 2020 |
|
#
?
May 25, 2020 09:32
|
|
|
rotor posted:I feel like actually having to do some vetting of your dependencies is maybe not the worst idea on earth, nor do i really see how tracking different versions of files is somehow beyond the purview of a version control system. do you work in a company of 10 people or something Aramoro posted:How would you poo poo up your version control by maintaining your dependencies in there?
|
|
#
?
May 25, 2020 09:38
|
|
|
your churn rate must be pretty insane if the initial checkout time is your most important consideration
|
|
#
?
May 25, 2020 09:46
|
|
|
Sagacity posted:how the hell would you even manage transitive dependencies this way? 'vendor' them too? Dependencies are pretty static in general so it's not really a problem? The main time this happens is when we upgrade Wildfly to a newer version but that's a whole huge job anyway to re-qualify the new application server. Dependencies don't change often enough for it to matter. Our inital checkout is 9gb I think, 1.1 million LoC in the code we actually run through sonar, that's probably 80% of the codebase. That part, managing dependencies and initial checkout has never been an issue really. We've done this for a decade or so and it's never come up as an issue so I'm genuinely curious how it would cause problems, like describe a scenario where it doesn't work. Aramoro fucked around with this message at 09:59 on May 25, 2020 |
|
#
?
May 25, 2020 09:53
|
|
|
I create internal nuget wrappers and put stuff into nexus specifically because I've seen the mess you get with direct inclusion in source control when across 15 components/solutions there are 10 different versions of the same library that interact differently with another library and depend on two others bonus points: we no longer have the code to build some of these (I think another team does though)
|
|
#
?
May 25, 2020 10:37
|
|
|
Sagacity posted:sure, i guess if you like your 10kloc microservice becoming 100mb+ of source code on disk and slowing down every new checkout, then wonderful CI does new checkouts
|
|
#
?
May 25, 2020 10:59
|
|
|
Jabor posted:your churn rate must be pretty insane if the initial checkout time is your most important consideration and since you can't distinguish between your own code and "vendored" code (since you've thrown it all into the same repo) you can't do any meaningful caching things that can be resolved by not taking this insane approach in the first place
|
|
#
?
May 25, 2020 11:53
|
|
|
are you using some horrible vcs where adding a directory of files that rarely ever change somehow imposes huge costs on every other change that doesn't touch those files? victorian-style performative fainting over hundreds of megabytes like it's still 1996 is the sort of thing that leads to making objectively lovely tradeoffs
|
|
#
?
May 25, 2020 12:10
|
|
|
Sagacity posted:as the poster above me points out it's not just new developers doing checkouts, it's your CI system all day long Why is it insane though, give me a senario where it breaks things. Or is it just 'makes the checkout take longer'. Like I say I'm asking because it's not been a problem for us at all, but then we tend not to change dependencies that often. Edit: wait are you suggesting building your dependences from thier sources, when you say thrown the code in with your own you're just dumping in the sources and building those as part of your build?
|
|
#
?
May 25, 2020 12:41
|
|
|
a lot of ci/cd setups will clone with --shallow or whatever anyway so the history of all those deps changing won't be there.Sagacity posted:sure, i guess if you like your 10kloc microservice becoming 100mb+ of source code on disk and slowing down every new checkout, then wonderful this is the most "i can conceive no other world than javascript" post that has ever been made
|
|
#
?
May 25, 2020 13:37
|
|
|
Aramoro posted:Why is it insane though, give me a senario where it breaks things. Or is it just 'makes the checkout take longer'. It definitely makes life needlessly miserable if you work on a team that is distributed world-wide and your "amount of crap I need to build The Thing is many tens of GBs and it's on a sever 8k miles away." Put yer binary garbage in artifactory or a CDN or _something_ with a local mirror that does not involve having to git clone 40GBs of garbage. oops my connection hiccuped so now I get to start the clone all over again hooray. if yer made of money you can setup multiple p4 masters worldwide with gobs of bandwidth between them; that works p well tbh. except for the daily frustrations of having to deal with perforce of course
|
|
#
?
May 25, 2020 14:08
|
|
|
Aramoro posted:As soon as you say 'If you don't want to you can just commit to master directly' then that becomes the only process because people are vain and arrogant and won't follow a process with even a single more step if they don't have to. Obviously 'they' know thier change is all fine and good, it was the other rear end in a top hat that broke it. They were going to break everything with their crappy commit either way. Without PRs you have to fix it immediately. With PRs you don't. There are many situations where the former is better.
|
|
#
?
May 25, 2020 19:08
|
|
|
Phobeste posted:this is the most "i can conceive no other world than javascript" post that has ever been made instead I am happy using maven and cargo. the former is even shaggar approved. i work on an application framework based on spring boot. thanks to the magic of maven we can provide dependency management for most commonly used dependencies through our landscape. so, teams simply bump the version of our framework and magically all of the other common third-party dependencies they use get upgraded as well (and are vetted so that the versions we list as being dependency managed are actually compatible with each other) next to that, I'm sometimes ask to help out teams with some troubleshooting. it's really nice if I can just quickly check out their repo, potentially quickly upgrade it while I'm at it, and go about my business that this is very alien to some of you and seemingly "1996" or "javascript" indicates you may want to rethink your current position
|
|
#
?
May 25, 2020 19:10
|
|
|
abigserve posted:Not having PRs breaks like every ci/cd thing ever unless you run on changes to every branch which'd be duuuuummb lastjob did this for a while, every time someone did a "git push" it would fire off a jenkins run ('suite of jenkins runs'), i liked it but it didn't scale
|
|
#
?
May 25, 2020 19:20
|
|
|
it was kind of cool working in .NET before it had a package manager / package ecosystem. if you wanted to ship a library, you had to think very carefully about which dependencies to require and most libs were just standalone and you could easily check them in or stick them on a shared drive somewhere. package-manager-based ecosystems make it so easy that devs get lazy and any library you depend on is likely to bring in a tree of 100 other dependencies. I guess what I'm saying is, don't release a new language without a robust and feature-ful standard library plz.
|
|
#
?
May 25, 2020 19:22
|
|
|
Sagacity posted:sure, i guess if you like your 10kloc microservice becoming 100mb+ of source code on disk and slowing down every new checkout, then wonderful
quote:how the hell would you even manage transitive dependencies this way? 'vendor' them too? yes As I said earlier, the disk space considerations become an issue and make the extra expense and effort worth it as your org grows very large - a thousand devs, maybe? idk where the line is, i've only worked in smaller 40ish dev shops and huge companies. But the objections you raise are just sort of trivial imo and the expense of running nexus or artifactory or whatever is not.
|
|
#
?
May 25, 2020 19:28
|
|
|
|
| # ? Oct 11, 2024 08:36 |
|
|
Does anyone know anything about these “mini program QR codes”, apart from the garbage name: Looks like Facebook made a circular QR code in 2016, and 3 years later Tencent stole it and rotated the lines by 90 degrees. Not as crazy as Microsoft’s colour codes but still lock-in to a web service. Facebook Messenger Code: 
MrMoo fucked around with this message at 19:35 on May 25, 2020 |
|
#
?
May 25, 2020 19:32
|
|
