Skip to content
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

Smaller Debian/Ubuntu package? #1113

Open
hyiltiz opened this issue Jan 15, 2020 · 3 comments
Open

Smaller Debian/Ubuntu package? #1113

hyiltiz opened this issue Jan 15, 2020 · 3 comments

Comments

@hyiltiz
Copy link

hyiltiz commented Jan 15, 2020

Not sure if package maintenance is also part of this project/issue tracker. If not, please feel free to close it so I'll get in touch with the Debian maintainer.

apt install yi in Debian testing tries to install over 146Mb worth of packages (even excluding suggested packages) in a system that already has ghc and stack and most common haskell libraries installed, while pandoc package is about less than 50Mb. Is it posisble to package yi to a respectable size as compared to, let's say, vim or neovim, less than about 30Mb? It would make more accessible for end-users to try it out; personally, I'd rather not install a 150Mb worth of "vim replacement".

@noughtmare
Copy link
Member

I think the problem is that Yi also needs all the source code of dependencies, because configuring the editor requires recompiling it. I think Pandoc is only a binary and does not include any Haskell source code. So the main way for making Yi more accessible would be to implement a configuration file (or DSL) based configuration system that doesn't require recompilation.

@hyiltiz
Copy link
Author

hyiltiz commented Jan 15, 2020

If the lack of such config file support implies it is not yet time to design one in Yi's current state, I'd guess the easiest way to solve this issue and provide a end-user friendly binary package would be to simply expose an internal data structure via Read and Show for the time being before v1.0 is released. It may not be as enpowering as recompiling the editor, but would surely make it much more portable at a small development cost.

@noughtmare
Copy link
Member

I think the biggest problems are that the configuration is not stored in one place and that not all configuration is plain data, some parts of the configuration are functions or even IO actions, so it is not possible to simply use the Read and Show interface. Issue #1069 tracks configuration issues and goes into more detail about where each part of the configuration is stored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants