Sole solution that contains everything of neo core

[Jim8y]

Summary or problem description It has being painful to maintain multiple projects while every single one of them has some sort of relyance on others. It is hard for new developers to find code they want and hard for old developers to address the issues in the project. If there had some reasons to split neo core into multiple subprojects, now we have much more reasons to put them back together into one.

Do you have any solution you want to propose?

A sole C# solution that contains every neo core projects and tools. A solution with a structure like this:

• cryptography
• core
• compiler
• vm
• plugins
• cli
• examples
• documents
• dockers
• scripts
• benchmark
• ...

Neo Version

• Neo 3

Where in the software does this update applies to?

• Compiler
• Consensus
• CLI
• Plugins
• Ledger
• Network Policy
• P2P (TCP)
• RPC (HTTP)
• SDK
• VM
• Other:

[Jim8y]

@erikzhang @shargon Please consider

[cschuchardt88]

I do agree with this. However i do believe some core features should be split up to allow other flavors dotnet framework types to work; like dotnet Maui for example, problem for that is because of the asp.net portion of neo core.

[Jim8y]

I mean put them into a single solution, different project can still have different dotnet framework, right?

[lock9]

I've seen this before... It did not end well for me lol

[vncoelho]

I think the same, @lock9 . It is better to have things modularized and split. The problem here is about integration tests, branching control and others.

[cschuchardt88]

@vncoelho @lock9 we are talking using one repo, i believe

[vncoelho]

I am as well, everything was one repo in the past

[lock9]

Yes, I'm aware. I've lost this battle before hahaha. I agree that we have a problem with repositories, but a mono repo is not going to happen (trust me, I've been there). We could try to have another repo that has 'subpackages'.

[EdgeDLT]

To offer an outside perspective, the current separation makes it very difficult for me to follow changes and to find or reason about code I care about. Though I don't contribute code, I can only imagine the monorepo approach makes refactoring, testing, releasing, and onboarding new contributors easier.

It is better to have things modularized and split.

Can you explain the main benefits to me? Components can still be split into packages while retaining the benefits of a single repo, right?

[cschuchardt88]

Can you explain the main benefits to me? Components can still be split into packages while retaining the benefits of a single repo, right?

yes that's correct.

I believe having a good foundation of one repo will really fix a lot of jumping through hoops and overstepping on/over each other. Just look at dotnet project on github itself prefect example of this one repo approach. But also has different ones for web and others. But all dlls for the framework of dotnet is one repo.

[Jim8y]

@lock9 @vncoelho I wasn't there when the decision of spliting repo was made, can you tell me where can i find the dicusion ? Almost every blockchain projects use mono repo for their chain, currently neo is the only one to split it, I totally have no idea why this happens. If branching and other things are the problem, why projects like E-letter chain and B-letter chain can do that.

[Jim8y]

Yes, reasons to split it. But, why only neo split it?

[lock9]

@Liaojinghui I can't remember how it happened. Afaik, it has always been like this. I'm in favor of a mono repository. Once, I was PO of the core devs, and one of my battles was to try to move things to a mono repo. As you can see, it didn't work out 😂

[Jim8y]

@Liaojinghui I can't remember how it happened. Afaik, it has always been like this. I'm in favor of a mono repository. Once, I was PO of the core devs, and one of my battles was to try to move things to a mono repo. As you can see, it didn't work out 😂

@lock9 Let's restart the battle, we shall never surrender.

[cschuchardt88]

How about I don't care what the problem is. This needs to happen or else nothing is going to get done in a timely fashion. I'm sick of these roadblocks preventing the community from moving forward. These excuses need to stop.

[lock9]

My dudes, I know exactly how you feel. I know how confusing it is to manage different repositories in different branches and states. This makes you mad because you don't know the state of things. Versions don't match. PRs need to be approved in the correct order. That being said, you have my blessing to fight this battle, as I believe you are fighting for a good cause. I don't think you will succeed, but we can dream of it.

Here, take this AI-generated lucky amulet with you

[Jim8y]

I understand all your concerns, but the simple question is WHY ONLY NEO

[lock9]

I understand all your concerns, but the simple question is WHY ONLY NEO

I'll be honest with you: Some people are against it. Like @vncoelho and @erikzhang.

They have their reasons.

[Jim8y]

How about I don't care what the problem is. This needs to happen or else nothing is going to get done in a timely fashion. I'm sick of these roadblocks preventing the community from moving forward. These excuses need to stop.

@cschuchardt88 Changes are happening, no more excuses, no more endless waiting, no more ignoring bugs and issues, we have discussed problems, which are also your concerns, during the community meeting, and we will standardize the core maintaining.

[vncoelho]

At the time the split was done, it came with several good improvements in the overall design of Neo core as a module. There were several good changes that happened with it.

In fact, things could be in same repo. But, at that time, the division appeared as a good logic.

If that is not the case of today, fell free to move this forward.

[vncoelho]

The extra we have nowadays is that without the constant presence of @erikzhang it becomes even harder to maintain different repos.

A strong point I would like to highlight is that if you decide to go this way, please let's keep the 'main' branch stable full time with modules,vm and client. Do not merge PRs that modify neo core library or vm without compatibility.

[Jim8y]

A strong point I would like to highlight is that if you decide to go this way, please let's keep the 'main' branch stable full time with modules,vm and client. Do not merge PRs that modify neo core library or vm without compatibility.

@vncoelho compatibility should be ensured by tons of tons of test cases. And we can work together to further ensure that.

[shargon]

I think that before making the decision to join or not, different questions must be resolved:

• What will happen with the nugets?
• Is it possible to use github submodules?
• What repos we want to join?

[Jim8y]

@shargon

I think that before making the decision to join or not, different questions must be resolved:

• What will happen with the nugets?

1. Simply put them together, even put solutions under the same repo will also work, nothing to do with the nugets.

• Is it possible to use github submodules?

Submodules wont work since the core to this is to change the dependencies from nugets to relative path.

• What repos we want to join?

Repos that should be put into a single repository should be put in. Just like, Ethereum, Bitcoin, Solana, and all other blockchain projects, including neogo.

[roman-khimov]

What I've seen happening in the current structure is:

• people forgetting to update some dependent modules
• inability to build the master state of everything
• inability to properly test the whole system because of the two reasons above
• black build magic like in https://github.com/nspcc-dev/neo-bench/blob/master/.docker/build/Dockerfile.sharp.sources.from_local_dependencies
• every installation requiring some actions with plugins because the default core is hardly a usable node

What I've not seen is any benefit to the kind of modularization we have. We're wasting time and effort for nothing, I think. So I'd vote for repo and build simplification for sure. You also know the way NeoGo is, one repo (except for the dbft lib) and one binary.

[Jim8y]

What I've seen happening in the current structure is:

• people forgetting to update some dependent modules
• inability to build the master state of everything
• inability to properly test the whole system because of the two reasons above
• black build magic like in https://github.com/nspcc-dev/neo-bench/blob/master/.docker/build/Dockerfile.sharp.sources.from_local_dependencies
• every installation requiring some actions with plugins because the default core is hardly a usable node

What I've not seen is any benefit to the kind of modularization we have. We're wasting time and effort for nothing, I think. So I'd vote for repo and build simplification for sure. You also know the way NeoGo is, one repo (except for the dbft lib) and one binary.

What i gonna do is make neoC# more like neogo, i think neogo has a way better structure and way better tool system.

[cschuchardt88]

What I've not seen is any benefit to the kind of modularization we have. We're wasting time and effort for nothing, I think. So I'd vote for repo and build simplification for sure. You also know the way NeoGo is, one repo (except for the dbft lib) and one binary.

I dont think C# should be one binary. Reason being this won't work for other dotnet frameworks like Unity Maui Standard and more.

[AnnaShaleva]

What I've not seen is any benefit to the kind of modularization we have. We're wasting time and effort for nothing, I think. So I'd vote for repo and build simplification for sure.

I feel exactly the same, the current modules are hard to build together, hard to develop and hard to maintain. I've faced with a series of GitHub repos made by Neo developers that are trying to put neo-node, neo, neo-modules, neo-vm and etc. together into one solid repo just to be able to build it. See https://github.com/devhawk/neo-monorepo and our neo-bench example Roman has provided, it's really painful to build all of these modules, and it takes a lot of time for the new developers to start.

Recently we had 3.6.1 release of neo-modules with core compatibility fix (https://github.com/neo-project/neo-modules/pull/830) just because of the fact that neo-modules is a separate repo that was not tested for compatibility before the release. So moving all the modules into a single monorepo allows us at least to make the code maintainable.

At the same time we still may have different binaries for the modules, IINM, it's possible with monorepo. But we have to ensure that every PR at least doesn't break the rest of the repo's parts, and with monorepo it's just easier.

[gsmachado]

@Liaojinghui and all: I'm a big fan of monorepos. ❤️

However, there's just one thing I would keep separate: compiler/SDK.

[shargon]

@Liaojinghui

Submodules wont work since the core to this is to change the dependencies from nugets to relative path.

This can be solved with two clicks in prepare-environment.bat

[Jim8y]

This can be solved with two clicks in prepare-environment.bat

@shargon why would we do that then, why make neo different than any other blockchain projects and possibly all other projects. I mean, come on, "neo core" has being famous of hard to use now. Easier for us to maintain (i doubt that) but hard for everyone to use.

[cschuchardt88]

Problem i run into is. Waiting for neo.dll or any others to be published in order to update another project repo code for new changes.

[shargon]

This can be solved with two clicks in prepare-environment.bat

@shargon why would we do that then, why make neo different than any other blockchain projects and possibly all other projects. I mean, come on, "neo core" has being famous of hard to use now. Easier for us to maintain (i doubt that) but hard for everyone to use.

I'm agree, it wasn't joined because Erik thought it was better that way.

[lock9]

However, there's just one thing I would keep separate: compiler/SDK.

It won't be a mono repo, and the problems will continue. Why keep the compiler and SDK out? It's the same as keeping neo-modules out. They need to work with the latest version too

[cschuchardt88]

neo-express should be in separate repo than core.

[Jim8y]

neo-express should be in separate repo than core.

definitely not everything in the core. @roman-khimov will help us to build the new core repo.

[shargon]

We will start with neo-vm, next neo-modules, step by step.