-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
[Feature]: Full development environment #8
Comments
I've worked with the repo tool (I develop Android, where repo is used for everything.) (small note: the projects directory would have to be pre-created, though you could run a script to initialize repo which cannot be done directly on github and sync everything.) |
Does this mean just the folder would need to exist, or do the repos need to also exist pre-cloned? I was under the impression that Repo would pull down the repos itself as part of the syncing process (though if not then it's still not a huge deal like you said, can just bootstrap it) |
The folder would need to exist. You could include a bootstrap sh file that would run repo init and repo sync. The repos would be synced by Repo, no need to include them in git. (that's a lot of "repo") |
I've made an example manifest file just to show how it'd work. <?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="github" fetch="https://github.com/" />
<default revision="master" remote="github" sync-j="4" />
<project name="PretendoNetwork/account" path="account" />
<project name="PretendoNetwork/friends" path="friends" revision="nex-go-rewrite" />
</manifest>
You'd define the "remote" as GitHub or any other git service. Then, if you wanted to, you'd define some defaults such as the default branch, remote and how many threads should be used to sync. Then you define the repositories, or "projects" as repo calls them. You could define specific branches, or not define any (defaults used). The "path" is where it would be stored. For example, if repo was init in |
Checked Existing
What feature do you want to see added?
An easy to setup and run development environment that runs essentially the entire network locally
Why do you want to have this feature?
Currently it's very difficult for new people to contribute as there are hundreds of repositories and many many servers which all talk to each other. Many of our servers/tools also lack instructions for how to run/build them, and it's not clear how services communicate with each other. All of this combined makes it very difficult for new people to join and get setup
Any other details to share? (OPTIONAL)
This issue is related to both PretendoNetwork/Inkay#57 and PretendoNetwork/Martini#13, but has a much larger scope. Discussion about a full development environment was beginning to happen on the Inkay issue which was not a good place for that to happen. This issue is where future discussions of a full development environment should take place
Some basic requirements for this would be, but not limited to:
All of these requirements already have some suggested solutions
For redirecting requests we have https://github.com/PretendoNetwork/mitmproxy-nintendo, which is already designed to redirect requests from Nintendo's servers to our production ones. By modifying
pretendo_addon.py
and changing the systemshosts
file you can easily point requests to a local server. It was also pointed out by @DaniElectra on Discord that mitimproxy now has better support for older TLS versions, which also improves this:As for the custom patches, we have 2 solutions for this already:
test
environment and swapping between the two local accounts. This is done to isolate the accounts and give them their own sets of URLs, which our patches can then patch without affecting the normal production URLs of the "Nintendo" account. The 3DS has a 2rd account environment however calleddev
which should also have its own URLs. We should make a dedicated developer tool for this, which is essentially just a more powerful Nimbus/https://github.com/zaksabeast/3ds-Friend-Account-Manager that lets developers make and manage a 3rd local account, and update our URL patches accordingly? This is the best we can do right now I think. Alternatively, we know that there is a frd sysmodule decomp/reimplementation being worked on (this is not public so I won't say any more than that). Once/if that becomes public, we could possibly use this to replace our URL patches entirely and instead swap the URLs on the fly. This idea has been brought up internally before, since https://github.com/zaksabeast/3ds-friends-sysmodule exists, but this reimplementation is incomplete (lacks all NEX functionality) so it can't be used. However this new reimplementation should have NEX support, so maybe that's more viable? Regardless, one issue still remains: custom SSL certificates for Miiverse. Since we don't have a Meowth equivalent for the 3DS, this means that the Miiverse app does not have any SSL patches and we must use custom ones for local development. This is still a barrier to entry, which hopefully we can solve in the future (either on the consoles or off)As for pulling down the repos, I had originally suggested submodules (despite knowing they were not the best tool for the job). This was (understandably) shot down. However I think I've found a better tool? I discovered https://gerrit.googlesource.com/git-repo recently which seems to be designed for this sort of workflow. You provide the tool a "manifest" file which contains the links to remote repositories and the paths they should have on disk, and this tool helps manage them. It's used as part of Android development so if it's good enough for Google, it should be good enough for us? We can just have Repo use the manifest to pull down the repositories needed for the development environment
Then we just need a way to run said servers. Maybe something like https://github.com/MatthewL246/pretendo-docker?
My proposed structure for a
developer-environment
repository would look something like:Where
projects
would NOT come pre-populated and would instead be created using RepoWorking with Miiverse (and other browser-based apps) is something that has been mentioned a number of times. These are pretty large barriers to get past, since they have a combination of issues. These include, but are not limited to:
A number of suggestions for this have been proposed. See #5 for more details. We essentially have 3 options:
The text was updated successfully, but these errors were encountered: