Comments (7)
from go-algorand.
I think submodules are somewhat clunky.
An alternative proposal would be to fork off libsodium-fork
, along with a minimal Go shim around it, into a separate repo, and import that using dep
vendoring (or, eventually, using Go modules). I think that fits into our dependency management plan better.
from go-algorand.
If I may add my own experience from wrestling with this same issue in the past. I would also like to preface this by saying that the code base I was working on consisted of about 120 "subrepos" and tens of millions of LOC so it might be overkill for go-algorand
's purposes and due to confidentiality I can't go into too much of the implementation details.
The first thing we looked at is git submodule
and almost immediately discarded that idea. As Alex said, too clunky, slow, won't play nice with branches, but worse of all requires constant developer tracking of the upstream code base and does not support versioning (at least easily).
What we came up with eventually relied on git tag
and a repo tags file (not unlike NPM, except it didn't exist at that time). Then using git hook
and some Perl glue we made it seamless to the developer team. This also had the advantage of extremely fast integration builds and tests using prebuilt binaries for any subrepo which was not touched (looking at Travis logs I think you already do something similar). And another nice feature was that one didn't need to git clone all 120 subrepos to bootstrap a dev environment because the hooks and the Makefile generator knew where to look.
Circling back to your dilemma, and this is where I'll show my ignorance as an outsider, these would be my questions to you: Do you really need to import the source? Can you just have prebuilt library releases in a separate repo and just link them? Does it matter if you have a monorepo or two sister repos?
If nothing else, I hope this gives you some ideas or you have a good laugh :)
from go-algorand.
If I may add my own experience from wrestling with this same issue in the past. I would also like to preface this by saying that the code base I was working on consisted of about 120 "subrepos" and tens of millions of LOC so it might be overkill for
go-algorand
's purposes and due to confidentiality I can't go into too much of the implementation details.The first thing we looked at is
git submodule
and almost immediately discarded that idea. As Alex said, too clunky, slow, won't play nice with branches, but worse of all requires constant developer tracking of the upstream code base and does not support versioning (at least easily).What we came up with eventually relied on
git tag
and a repo tags file (not unlike NPM, except it didn't exist at that time). Then usinggit hook
and some Perl glue we made it seamless to the developer team. This also had the advantage of extremely fast integration builds and tests using prebuilt binaries for any subrepo which was not touched (looking at Travis logs I think you already do something similar). And another nice feature was that one didn't need to git clone all 120 subrepos to bootstrap a dev environment because the hooks and the Makefile generator knew where to look.Circling back to your dilemma, and this is where I'll show my ignorance as an outsider, these would be my questions to you: Do you really need to import the source? Can you just have prebuilt library releases in a separate repo and just link them? Does it matter if you have a monorepo or two sister repos?
If nothing else, I hope this gives you some ideas or you have a good laugh :)
@jecassis, I think that there are two requirement that we absolutely need :
- Traceability - we need to be able to show what is the complete source code that was used to build our product. Using mystery, non-versioned library binaries defeat that goal. Versioned libraries are good only as long as their source code is available.
- Reusability - we need to make sure that all the resources that builds up our product and be re-evaluated from the ground-up. The best way to make sure this is the case is to compile the entire source code. ( which also give you control on which compiler you use )
Reflecting back, I can recall several companies I worked for, which failed with the above ( mystery library that cannot be rebuilt, etc.). These scenarios rarely plays into the company best interest.
from go-algorand.
Commendable goals, to be sure. Thanks for the explanation!
from go-algorand.
The Dev Ops team has determined that this is no longer applicable, we won't be implementing this issue. Also, no activity for 2 years, stale issue.
from go-algorand.
I have some concerns about this too. It appears that you are falling behind upstream libsodium as well. Wouldn't a patchfile or something make more sense to be able to integrate with upstream directly?
from go-algorand.
Related Issues (20)
- Official docker images are incompatible with windows server workers on github actions HOT 3
- Build: Flaky Ledger Catchup StateProof Verification Test
- The `DisableAPIAuth` config option causes requests to error if any auth token is present HOT 2
- As a beginner, how should I build my own chain? HOT 3
- The security vulnerability bounty page is "Not Found"
- Missing LedgerStateDelta from OAS spec (and therefore documentation and other SDKs apart from Go) HOT 1
- Measure consensus Nakamoto coefficient HOT 5
- goal should make extra information provided in some API requests available HOT 1
- Documentation and Config Generation: non-archival relays should retain last 20K or more blocks
- There are 11 pages of GitHub issues, some as old as 2019. Let's clean this up? HOT 1
- simulate fails with empty signature on a rekeyed account HOT 15
- Catchpoint is very slow HOT 3
- Add option to store and retrieve deltas HOT 2
- Node's ready status is incorrect while the node is starting HOT 1
- Buggy test?
- increase max lsig program size HOT 6
- Add access to incentive related consensus parameters HOT 3
- 3.24.0 - make - version of quic-go not supporting Go 1.21 HOT 1
- Algod docker image configuration support for ColdDataDir HOT 1
- request body too large HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-algorand.