8000 uploaded bash/coreutils/nginx/postgres/python/python-modules by qianxichen233 · Pull Request #197 · Lind-Project/lind-wasm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

uploaded bash/coreutils/nginx/postgres/python/python-modules #197

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

uploaded bash/coreutils/nginx/postgres/python/python-modules #197

wants to merge 1 commit into from

Conversation

qianxichen233
Copy link
Contributor
@qianxichen233 qianxichen233 commented Apr 30, 2025 •
edited
Loading

This PR uploaded bash, coreutils, nginx, postgres, python and python-modules to lind-wasm repo. These applications are directly copied from lind-nacl codebase without any modifications yet

A seperate PR for dedicated build process for these applications in lind-wasm will be raised once this PR is merged

@ci-response-bot
Copy link

Commit d0835d5: Build Success

@ci-response-bot
Copy link

Test Report

View HTML Report
View JSON Results

@rennergade
Copy link
Contributor

Per our conversation today, I think it makes sense for us to do a few things here.

  1. My preference is we use unmodified source code for each application but use the same version we've used in the NaCl experiments. My main point here is that we don't want to preserve unnecessary artifacts/changes we may have added to build for NaCl. If we need to comb through these for fixes the code is still preserved in that repo.
  2. Also prefer to add things in separate PRs
  3. I think applications actually would be a good use for a sub-module since that code isn't dependent on the mono-repo, but not sure best practice. Would love to hear thoughts from @lukpueh an @m-hemmings on this.

@lukpueh
Copy link
Contributor
lukpueh commented May 2, 2025 •
edited
Loading

Per our conversation today, I think it makes sense for us to do a few things here.

  1. My preference is we use unmodified source code for each application but use the same version we've used in the NaCl experiments. My main point here is that we don't want to preserve unnecessary artifacts/changes we may have added to build for NaCl. If we need to comb through these for fixes the code is still preserved in that repo.

It would be extremely helpful to have a reference to the repo and revision, from where all of this was copied. For an outsider it's hard to trace this back to any prior development.

  1. Also prefer to add things in separate PRs

I think it does not make a difference, if you submit 1 PR with 10M lines of code, or 10 PRs with 1M. Either way, code review is not feasible.

  1. I think applications actually would be a good use for a sub-module since that code isn't dependent on the mono-repo, but not sure best practice. Would love to hear thoughts from @lukpueh an @m-hemmings on this.

There are two aspects to this question:

  1. Do you want to keep these third-party apps in dedicated git repos?

Definitely yes, otherwise, that is, if you copy the entire tree into your monorepo and commit on top of it, you'll have a very hard time to sync back any changes from upstream (e.g. security fixes). Therefore, I strongly suggest, you keep a fork for each of the apps and then pull them into lind-wasm, e.g. using submodules.

  1. Submodule yes or no?

Probably yes. An alternative would be to configure your build scripts (bazel, lindtool, make, ??) to simply clone your apps at build time. This makes sense, if there is a lot of (downstream) development in your apps and you don't want to constantly update the submodule references, but just build from the tip of development.
You should use git submodules, otoh, if you do want that revision control, and if you want to keep it separate from your build scripts.

Btw. I think the same strategy makes sense for other third-party projects, currently copied into lind-wasm (glibc and wasmtime).

@lukpueh
Copy link
Contributor
lukpueh commented May 12, 2025
  1. I think applications actually would be a good use for a sub-module since that code isn't dependent on the mono-repo, but not sure best practice. Would love to hear thoughts from @lukpueh an @m-hemmings on this.

There are two aspects to this question:

  1. Do you want to keep these third-party apps in dedicated git repos?

Definitely yes, otherwise, that is, if you copy the entire tree into your monorepo and commit on top of it, you'll have a very hard time to sync back any changes from upstream (e.g. security fixes). Therefore, I strongly suggest, you keep a fork for each of the apps and then pull them into lind-wasm, e.g. using submodules.

  1. Submodule yes or no?

Probably yes. An alternative would be to configure your build scripts (bazel, lindtool, make, ??) to simply clone your apps at build time. This makes sense, if there is a lot of (downstream) development in your apps and you don't want to constantly update the submodule references, but just build from the tip of development. You should use git submodules, otoh, if you do want that revision control, and if you want to keep it separate from your build scripts.

Btw. I think the same strategy makes sense for other third-party projects, currently copied into lind-wasm (glibc and wasmtime).

Never mind my recommendation from above. I understand now that these "apps" are basically test data, and not meant to be synced with upstream. In that case, I'd not bother with separate repos or submodules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@rennergade rennergade Awaiting requested review from rennergade

@yzhang71 yzhang71 Awaiting requested review from yzhang71

@Yaxuan-w Yaxuan-w Awaiting requested review from Yaxuan-w

At least 2 approving reviews are required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@qianxichen233 @rennergade @lukpueh
0