Closed kyazdani42 closed 2 years ago
cseickel
commented
2 years ago Hey @kyazdani42, I totally understand where you are coming from concerning the workload and I know the entire community appreciates the hard work you guys have put in. Your idea has merit but I don't want to jump into anything. Let me give this some real thought and get back to you.
cseickel
commented
2 years ago Since neo-tree was started well after nvim-tree, you have been able to use libraries and a better plugin architecture, with the approach of writing plugins for the tree.
Being first is not the best place to be in software development! I certainly learned a lot from your code base and saw where the growing pains were. Also, @MunifTanjim really did half of the work with the Nui library.
Also we should think of new users. When they come to neovim, why is there multiple trees written in lua ? It might be confusing for them (it has been for me during my vim days with the plethora of tree plugins written in X languages).
No one will ever agree on this point. There are those that would agree with this statement, and there are others that say choice and competition is important. I agree with competition being healthy for the ecosystem. There are a lot of features in neo-tree only because "nvim-tree did it!", and it makes neo-tree better. Conversely, I think there are some features that you have where I said "no, but here are the configuration points for you to implement this yourself." In that case, it's good that they can just use nvim-tree if they don't like my response.
And lately, i've been a bit tired to maintain this repository. It has been quite a while, and the development on it is very mechanical to me, and it has started to turn to project management quite a bit, which i don't particularly like (thanks alex for doing that better than me though !).
This is the heart of the issue. I 100% appreciate where you are coming from. If you don't want to keep managing the project, I guess the choices are to pass it off to someone else or just call it deprecated and point people to other alternatives.
The way I see it there are four interested groups:
Speaking for myself, I'm not striving to be hugely popular because I'm not eager for more work. I also wouldn't mind if you did push all of those users my way. I will just do the amount of work that I can and not let it consume me. I'd likely ask for volunteers to help if it gets to be too much work. (As a side note, I am actually about to start a new job so will likely have less time to focus on my own project over the next few months...)
For you, @kyazdani42 and @alex-courtis, if it's more chore than satisfying, absolutely don't keep doing it. If you were interested in still doing neovim tree related work but would rather consolidate our efforts by contributing to neo-tree instead, then hell yeah, come on over! Discussion over, glad to have you.
What's good for your users? I can't say, but hopefully some of them might chime in.
What's good for new neovim users? I'll concede that one popular choice is good for them, which is what nvim-tree has been so far. Neo-tree would be a fair replacement for that familiar tree so I'll mark this as a positive for them to have one less choice to make.
Of course, there is always the possibility that someone else wants to fork it and continue the work on their own.
So in the end, what do you think ? I'd be happy to discuss that a bit more, and if we decide to promote neo-tree as nvim tree main explorer, how would we proceed ?
My conclusion is that it's up to you and I'm OK either way. If there are nvim-tree users that want to do the work to keep it going but you don't, then let someone take it over instead of trying to roll them over to neo-tree.
If you do want to deprecate, I think I would put a notice on your README, a pinned issue, and then do a reddit post. Eventually you can archive it too.
cseickel
commented
2 years ago Hey guys, I just stumbled on a related discussion at https://github.com/kyazdani42/nvim-tree.lua/issues/1474 and I'll just respond to some of your questions here since this seems to be a continuation of that conversation.
My motivation for creating neo-tree were:
You mentioned that features seem to be copied between projects. I will say that I did not keep up with nvim-tree at all so it was not intentional if we were adding features at the same time. It's possible that our users were egging this on because they would see something in the other tree and ask for it, or just ask in both projects to see who would do it. Some of them were just obvious improvements and I guess we converged on both priorities and development speed.
Documentation... It's not great. The help file is a little disorganized. It's just a chore to do and it's a hobby, so it is what it is. I would love it if someone else would clean it up but that's not happening.
Testing. It's really only lightly tested. I don't keep up with it that well but I do have just enough tests to know if something critical is broken. I'm not a hardcore test everything person myself, but I love it when other people contribute tests.
kyazdani42
commented
2 years ago Thanks a lot for this very detailed answer. I think you are right for most things, and following some of your opinions, i believe deprecating this project wouldn't be the right choice. I agree multiple projects doing the same thing is important, i wouldn't be using linux otherwise :) But since this is a simple project, i believe it is not too important in this aspect.
After some thinking, i believe i'd be happy to see nvim-tree as a basic "battery included, good default" option, less modular, neo-tree as you said is more modular, leaning towards power users.
But since i'm kind of tired to do project management and developing new stuff, i'd like to see if @alex-courtis has an opinion on this. It doesn't take too much time to just check on the notifications and answer people from time to time for me so i can still do that, and review PRs.
alex-courtis
commented
2 years ago neo-tree and nvim-tree are excellent products with active developers. nvim-tree has a very large user base and community.
Both are suffering some burnout and will experience maintenance difficulties in the future.
The ideal experience for the user would be to use nvim-tree as the "one preferred tree", with users able to continue to use it in a mostly unchanged configuration and UX. This can achieved by folding neo-tree into nvim-tree.
Cherry picking:
Functionality that requires merging and reworking:
Features should be stabilised, with a heavy emphasis on users extending via events/api. Some requested funcionality may not be extensible, however such decisions can be conservatively made.
My personal approach to such a merge is that it must be seamless, with automated and assisted migration that does not disrupt the user.
alex-courtis
commented
2 years ago After some thinking, i believe i'd be happy to see nvim-tree as a basic "battery included, good default" option, less modular, neo-tree as you said is more modular, leaning towards power users.
I have been struggling a lot with this recently.
Opinionated defaults are always desirable and suit new users, such as lunarvim users. Opinionated defaults also suit the power user, providing they have the rich "plugin system" that neo-tree aims to provide.
Recently I have been allowing what I call "configuration creep" in which I have been reluctantly adding configuration options, due to very vocal users.
But since i'm kind of tired to do project management and developing new stuff, i'd like to see if @alex-courtis has an opinion on this.
I'm a pure software engineer by profession. I have organically become engaged in product management and UX with nvim-tree and (to my great surprise) I'm actually enjoying it and would like to continue.
Of course I'd still like to continue lua plugin development, even with a focus on quality / review.
alex-courtis
commented
2 years ago This is a difficult topic, however it should be discussed:
nvim-tree and neo-tree will soon not have sufficient mainainers. They may become "one of those OSS projects" that receive no bug fixes or features from the maintainers, with PRs from external contributors receiving no attention or action. I am always disappointed with such project: I submit a bugfix or feature PR and it is never looked at.
Consolidating efforts on one project is a solution. It is not easy.
The transition from a project owner to a maintainer is difficult.
Decisions are difficult, with conflict resulting in stalled changes. I call these "headless OSS projects", which often appears to occur when the project owner leaves it in the hands of multiple maintainers.
An OSS project needs an owner to break deadlocks. Alternatively, a dedicated decision make can be defined. A product manager can suits such a role, and I'd like to suggest someone like @gegoune. This role will involve asking a lot of higher level questions.
cseickel
commented
2 years ago You have a lot of insightful points @alex-courtis. Let me clarify my position on everything.
The ideal experience for the user would be to use nvim-tree as the "one preferred tree", with users able to continue to use it in a mostly unchanged configuration and UX. This can achieved by folding neo-tree into nvim-tree.
I am not positive what you mean by folding, but I don't think any merging of code bases makes sense. They are both mature projects which are not particularly compatible in a way that would enable sharing code. If you mean developers joining the other project, I will say that I am very happy with neo-tree and I would not drop it's code base to work on another project. In fact, I love the code base. It was custom built just for my enjoyment!
I'm a pure software engineer by profession. I have organically become engaged in product management and UX with nvim-tree and (to my great surprise) I'm actually enjoying it and would like to continue.
Funny, I am the opposite. I am actually a solutions architect / full stack developer on a small team, so I am used to the full gamut in my day job but prefer the pure software engineering aspect for my hobby project. I'm comfortable with support and project management but actively try to reduce the amount that is needed when making changes.
nvim-tree and neo-tree will soon not have sufficient mainainers. They may become "one of those OSS projects" that receive no bug fixes or features from the maintainers, with PRs from external contributors receiving no attention or action. I am always disappointed with such project: I submit a bugfix or feature PR and it is never looked at.
For myself, at least for the foreseeable future, I think I am at my floor as far as involvement in neo-tree. I am still very active in responding to PRs. The ones that are sitting there now are WIP where the submitters have gotten busy. I also respond to bugs and how-to questions pretty quickly, although I admittedly am less helpful lately when I am sure it is a conflict with another plugin or user configured autocmd.
Where I have really slowed down is new features. That's in large part because it is done for me. It has all of the features I personally want, and I am not that motivated to add features for other people. I get roped in when others submit PRs where the features are not quite complete in my eyes and I just add some polish to it. Other than that, I am in maintenance mode.
I have personally been thinking about making an announcement that I don't intend to personally do any feature work going forward, and if you want a new feature, please submit a PR. I would love for someone to assist with answering how-to questions and screening bugs, but it doesn't seem like something anyone could be interested in doing. I want to continue to be the sole reviewer for PRs because I need to make sure the code stays decoupled and in the functional style, and most people want to push it towards object oriented. I also want to make sure that everything is polished and flexible, and not just scratching an itch for one person's unique situation.
cseickel
commented
2 years ago I have one thought I will throw out there. Since @alex-courtis and I are both attached to our own projects and don't want to just join the other, there may still be opportunities to share code. We could do that by splitting out functionality into separate projects to act as libraries like Nui.
For example, I had thought of doing that with neo-tree's event system and debounce code. It would not be much work to split it out and if it's helpful to you and would assist as a project maintainer, I would be willing to do so.
Git status parsing is another thing that was incredibly hard to do correctly and it would benefit the community if this was split out into a utility library that others could use. Right now I am stalled on an upgrade to this where I am trying to make the index status bubble up to parent folders correctly and return easily digestible flags instead of just the raw status codes.
If you have any thoughts like that where you have a module you are proud of and willing to share, or something you are having issues with and want to replace with a library, let me know.
alex-courtis
commented
2 years ago I am not positive what you mean by folding, but I don't think any merging of code bases makes sense. They are both mature projects which are not particularly compatible in a way that would enable sharing code. If you mean developers joining the other project, I will say that I am very happy with neo-tree and I would not drop it's code base to work on another project. In fact, I love the code base. It was custom built just for my enjoyment!
Merging is not quite the right term; I'm proposing a replacement of most of nvim-tree with neo-tree, as per @kyazdani42 suggestion:
So in the end, what do you think ? I'd be happy to discuss that a bit more, and if we decide to promote neo-tree as nvim tree main explorer, how would we proceed ?
neo-tree becomes nvim-tree, in a manner that preserves the nvim-tree user experience without any disruption.
alex-courtis
commented
2 years ago Since @alex-courtis and I are both attached to our own projects and don't want to just join the other, there may still be opportunities to share code.
No attachment here. Working on the most mature and well structured code base (neo-tree) is the desirable state. The difficulty here is preservation of the nvim-tree experience for the large number of users.
We could do that by splitting out functionality into separate projects to act as libraries like Nui.
That is a fantastic idea. The scope for extraction is great.
cseickel
commented
2 years ago Ok, I now have two possible paths in my mind:
neovim-tree project which supersedes both our projects.Number 1 is probably the most direct and efficient response to the original idea, but number 2 would be a greater benefit to the community.
NOTE: I don't want to shut down the neo-tree repo in any case because I promised reliability to my users. I plan on keeping it alive and at least updated to handle any breaking changes in future neovim updates.
alex-courtis
commented
2 years ago Let's call the new tree nvim-tree 2.0. It will contain neo-tree internals. To the user it will be indistinguishable from current nvim-tree
nvim-tree becomes a configuration of neo-tree, which supplies a default configuration that looks and behaves exactly like nvim-tree does now. It would have a setup function that translates all nvim-tree configuration to neo-tree's. Any functionality missing from neo-tree can be shimmed in the nvim-tree repo or added to neo-tree on a case by case basis.
Almost there. neo-tree would be imported into an nvim-tree 2.0 branch. There would be no translation involved: nvim-tree config, appearance, mappings and other UX would be the one and only way to interface with nvim-tree 2.0. The very small amount of missing functionality would be added to the branch. Upon completion of the 2.0 branch it would be flipped to master, with users not noticing that any change has occurred.
NOTE: I don't want to shut down the neo-tree repo in any case because I promised reliability to my users. I plan on keeping it alive and at least updated to handle any breaking changes in future neovim updates.
I appreciate your committment to your users, however a divergent fork creates a lot of unnecessary and time consuming work.
The overarching goal that I envision is to consolidate our efforts: yourself, kiyan, myself and the (many) community contributors work on the one and only tree nvim-tree 2.0. Developer time is limited and the optimal approach is to focus all the available time on one project. Losing your time to maintain neo-tree goes against that goal.
nyngwang
commented
2 years ago How about you guys making a Repo. defining a formal API interface for those features that are either can-be-share and/or too fancy to fits the definition of "battery included, good default" can be added like an add-on? Then any future feature can be loaded to both plugins. (I assume some ugly if-else are needed to make equivalent experience on both sides.)
What do you think?
alex-courtis
commented
2 years ago 2. We start extracting functionality into generic libraries one at a time which we will work on together and each individually incorporate into our respective projects. One day we will get to the point where there is nothing left but the UI and configuration layer. At that point we either stop, go to idea 1 above, or make an entirely new third generation
neovim-treeproject which supersedes both our projects.
That is the optimal approach.
It would require a lot of planning and collaboration between two tree projects as well as the extracted libraries.
We lack developer resources: yours and kiyan's time is reduced. There are not sufficient community contributors available.
alex-courtis
commented
2 years ago How about you guys making a Repo. defining a formal API interface for those features that are either can-be-share and/or too fancy to fits the definition of "battery included, good default" can be added like an add-on? Then any future feature can be loaded to both plugins. (I assume some ugly if-else are needed to make equivalent experience on both sides.)
- For maintainer(s), you never need to get "roped in" again. If someone wants something fancy but you are not interested in it, just show them how to create an addon by any existing example. Simply put a wiki somewhere, and maybe create a simple "hello world" addon template to fork. This also frees maintainers from thinking about what's the "good default" for these features you're not interested in.
- For users, the configuration of the main tree-plugin will be very concise. I will never need to think about "What else options do I need to disable on this conquer-the-universe plugin to just use those features I need?".
What do you think?
That's a fantastic idea and will be of great value to the user. This approach has been very successful for plugins like nvim-lspconfig, tagbar and vim-fugitive.
Maintaining two implementations of the API for two trees is possible, however we lack sufficient developer resources to define the API, implement it twice and extract functionality to feature plugins.
cseickel
commented
2 years ago As you said @alex-courtis, resources are limited so we should go for the most efficient rather than the ideal. For that reason, extracting out common functionality is probably not going to work. My other idea about making nvim-tree a configuration overlay is also probably not going to work because translating your api and configuration would probably be a lot of work. That also means that dropping neo-tree code into the nvim-tree repo and expecting users to have a seamless transition is also not going to work.
I think where that leaves us is that the most efficient use of dev resources would be to have you and @kyazdani42 join the neo-tree project and improve the experience for when nvim-tree users make the switch. I realize that nvim-tree is the more popular one right now, but if we are going to use the neo-tree code then it only makes sense to use that project and not dislocate the neo-tree users. If we did move neo-tree code to nvim-tree, then we would be inconveniencing both user bases because neo-tree users would have to update to your repo and not everything will translate properly for your users. Also, neo-tree has the advantage of being in an organization so it will make it easier to pass off ownership to the next generation of maintainers when the time comes.
I think what neo-tree really needs to act as a nvim-tree replacement is:
nvim-tree-renderer and nvim-tree-mappings. I picture these as sets of configuration that can be opted into and combined to make most people's configs much shorter.Honestly, this is still a lot of work but probably less than any other option and ultimately more productive.
Creating an add-on api is a really great idea as well, but I think that might come after the steps above.
alex-courtis
commented
2 years ago I think where that leaves us is that the most efficient use of dev resources would be to have you and @kyazdani42 join the neo-tree project and improve the experience for when nvim-tree users make the switch.
That is an option, however it will be quite disruptive from a user and developer perspective.
This begs the question: why not simply discontinue nvim-tree and direct the nvim-tree community to migrate to neo-tree?
cseickel
commented
2 years ago I think where that leaves us is that the most efficient use of dev resources would be to have you and @kyazdani42 join the neo-tree project and improve the experience for when nvim-tree users make the switch.
That is an option, however it will be quite disruptive from a user and developer perspective.
Yes, but I think it's less disruptive than migrating neo-tree code into nvim-tree. Obviously that would remove any disruption from neo-tree users. It is also better for the nvim-tree users that they are moving to the new code base to be explicit about the fact that this is something new and they need to look at their config fresh rather than expecting a smooth transition with their existing config.
This begs the question: why not simply discontinue nvim-tree and direct the nvim-tree community to migrate to neo-tree?
That is actually what I was trying to say. I just meant that we can do some work to prepare for them and make the transition smoother. There should have been a step 4: "Direct nvim-tree users to migrate to neo-tree."
Nvim-tree 2.0 as a superset/configuration of neo-tree is still a viable option in my head if you want to keep the nvim-tree name and repo going. Neo-tree in that case would be more like a library that nvim-tree is built on, just like neo-tree itself is built upon Nui. There will probably be a few things that don't translate, but I think you can get very close just by configuring the "filesystem" source.
In that situation, you can even link to neo-tree and Nui as submodules in your repo if you like. That would remove the explicit dependency and give you some more stability by being able to test upgrades for breaking changes before updates roll out to your users.
alex-courtis
commented
2 years ago It does not appear that we are reaching any consensus, and the topic of ownership and decision making has not yet been discussed.
My concerns are only:
nvim-tree is stable, performant and functional, with bugs being resolved swiftly and questions answered quickly. The codebase may be ugly in some places, however that is true of every large software project.
The idea of neo-tree -> nvim-tree is aimed primarily at engaging @cseickel as an nvim-tree developer. Codebase improvements are a desirable side effect which incurs considerable cost and risk.
@cseickel : will you consider joining the nvim-tree project as it stands? Countless thousands of users will benefit from and appreciate your time and expertise.
cseickel
commented
2 years ago The idea of neo-tree -> nvim-tree is aimed primarily at engaging @cseickel as an nvim-tree developer. Codebase improvements are a desirable side effect which incurs considerable cost and risk.
@cseickel : will you consider joining the nvim-tree project as it stands? Countless thousands of users will benefit from and appreciate your time and expertise.
I appreciate the trust you are willing to place in me by inviting me to the project, but I will have to decline. I am very happy with the state of neo-tree and to be honest with you, my continuing work on neo-tree is primarily due to it being my baby. I also feel an obligation to the users to continue it as-is without any unnecessary disruptions.
Neo-tree is MIT licensed and you are welcome to reuse any code from neo-tree that you want. I am also very open to any opportunity to collaborate on new features where we could share code or create libraries.
kyazdani42
commented
2 years ago Let just keep both projects. After reading the discussion, i understand they don't have the same goals and as such they should not share the same codebase.
Neo-tree is more oriented towards having a powerful scriptable modular tree, nvim-tree should stay simple, minimal and user friendly (so to speak).
When i created nvim-tree, it was of frustration of the slowness of all the other trees, specially nerdtree. I wouldn't like that complexity in the codebase transforms nvim-tree into a slow plugin.
Also, i wouldn't like adding libraries to nvim-tree, because it makes things less stable usually. Specially for such a small codebase i don't see the point of it.
I will give the ownership of nvim-tree to Alex. I will probably take a peek from time to time if help is needed, but nothing more.
Lets close this discussion :) @cseickel thanks for your time and answers. Keep up the good work on neo-tree !
devkvlt
commented
2 years ago I have a few suggestions..
The benefit of having a clean and simple codebase is that the project can pretty much run itself and you guys would only have to accept or refuse PRs. Currently, while nvim-tree is the best, the code itself is not clear and when a person tries to read it to fix some tiny issue, they go like "meeeh I don't know what this does and I don't feel like trying to decrypt it..." Remember this is a simple file explorer and not the Linux kernel, people would not commit great effort into contributing.
hinell
commented
1 year ago Neo-tree got serious issues with memory leaks, checkout this my reply: https://github.com/nvim-neo-tree/neo-tree.nvim/issues/393#issuecomment-1483763212
@cseickel @alex-courtis @gegoune
Hi :)
I want to discuss with you guys to see if maintaining nvim-tree and neo-tree in parallel is worthwhile. Since neo-tree was started well after nvim-tree, you have been able to use libraries and a better plugin architecture, with the approach of writing plugins for the tree.
Also we should think of new users. When they come to neovim, why is there multiple trees written in lua ? It might be confusing for them (it has been for me during my vim days with the plethora of tree plugins written in X languages).
And lately, i've been a bit tired to maintain this repository. It has been quite a while, and the development on it is very mechanical to me, and it has started to turn to project management quite a bit, which i don't particularly like (thanks alex for doing that better than me though !).
The only thing is: a lot of people are using nvim-tree. We have ~5k clones per day, with 1K8 unique cloners per day. Since last week, we have 50K clones and ~20K unique cloners. If we decided to switch everything to neo-tree, it would probably disturb many users for a while.
So in the end, what do you think ? I'd be happy to discuss that a bit more, and if we decide to promote neo-tree as nvim tree main explorer, how would we proceed ?
Feel free to tag more people that might be interested in discussing this :)