I'm not sure which tool should development efforts be directed to? My understanding is that sol should be deprecating eopkg, but last commit on that was 3 years ago. on the other hand getsolus/package-management which I believe is where eopkg's development happens, has only had 3 commits back in 2019 and 3 in 2018. With a pull request still open and hanging since 2018.

For people who'd like to help, where should efforts be directed where they would be at least considered and discussed?

The sol repository on Github is not being used. We are starting to move Solus-specific repositories to Phabricator. I have a local source tree where I am working steadily through sol, which I will eventually mirror to Phabricator (first privately for internal feedback and eventually publicly). Right now, I don't want collaborators on sol because I have spent far too much time designing it for other people to get up to speed and help me with the initial version. Please be patient.

As far as eopkg is concerned, you are looking at the correct repository. We have not been spending any more time developing it than absolutely necessary. A PR would have to contain a pretty important change for us to consider merging it at this point.

I understand how much people would like to contribute code to the project, but the simple reality is that a lot of the core tooling needs full rewrites and significant design effort. Much of the design changes have been in discussion for years now. And Josh and I both agree that we want to lay a solid foundation for those projects before letting people go wild with PRs. Until that work is complete, I'm not comfortable asking people to contribute to those projects.

If you are looking for ways to contribute code, I would suggest helping with bug fixes in os-installer and budgie-desktop. If there is something else you are eager to work on, I am available on IRC between 08:00 and 22:00 EST most days and will happily hear your proposals if I am not in meetings.

    DataDrake I hope the good ideas from eopkg's ux were ported over to sol.
    It has by far the best package manager command line structure I've had the joy of using.

    Do you have any comment on how far from a 100% complete initial version sol is atm? Also will there be a testing period before it replaces eopkg or will it be released on phabricator the day it's shipped?

        hyphens I hope the good ideas from eopkg's ux were ported over to sol.
        It has by far the best package manager command line structure I've had the joy of using.

        The first version of sol will be fully compatible with eopkg, with the only major exception being the removal of the pisi build system since we have ypkg. I may also consider switching from XML to JSON for the alternate output formats.

        hyphens Do you have any comment on how far from a 100% complete initial version sol is atm?

        sol is in the late stages of design and early stages of implementation. But I should caution that we cannot replace eopkg until the Software Center has been rewritten for sol.

        hyphens will there be a testing period before it replaces eopkg or will it be released on phabricator the day it's shipped?

        Testing for sol will happen in phases. The first phase will see the extensive testing in a VM environment, until I am convinced it will not break existing installations. The second phase will involve internal testing by the Solus Team, mostly to look for edge cases and pain points. The third phase will be an opt-in period where the community will be able to install sol along-side eopkg for testing. At this point the full source-code of sol will have been made public as well for people to look for bugs. Once we are satisfied that sufficient testing has taken place, we will make the necessary changes for sol to replace eopkg.

        I'm not going to give a timeline on sol, but I will say that ferryd and ypkg3 are higher priorities right now. ferryd has the highest priority. It is in the later stages of implementation and early stages of testing. ypkg3 is in the late stages of design and has been implemented far enough to have both a CLI and the ability to read and write package.yml files, as well as provide an intermediate representation of package.yml to allow for conversion between versions of the package.yml specification.

        kyrios You can also have a look at the brisk-menu if you want to contribute

        Excellent point!

                  a year later

                  DataDrake
                  any update on this?
                  also, please help me be less idiot on this "why do we need another pkg manager than eopkg for Solus?" is there major improvement we should expect when "sol" is implemented?
                  any link or page for me to read is welcome and ... Thanks a lot for your impressive work
                  did your PhD went well ( read about it on this thread https://discuss.getsol.us/d/6377-any-updates-on-sol/7 )

                      unclemez
                      As I said in that thread you linked to, if they had an update to give you would have it. But as I type this Bryan is streaming ypkg3 development on twitch, which was also mentioned in that thread as being a higher priority.

                      eopkg is a fork of the pisi package manager. It is written in python 2 which is a language that is EOL. So at the very least it would require being rewritten in python 3. The team do not want to use python for the package manager. One reason is if python is broken such as by people using pip to install/update python packages which may be incompatible with eopkg or overwrite something important (no matter how many times you say don't, people still do this) then your package manager is broken, have fun fixing that.

                      But it also gives them a chance to design things the way they wish and address long standing issues such as poor time out handling that is not currently fixable due to a library eopkg uses which returns a timeout as a success.

                      But no matter what it had to be rewritten and then go through extensive testing. It would no longer be based on pisi and even the name eopkg is a hold over from Evolve OS days. So in every way, it needs to die.

                          Harvey So in every way, it needs to die.

                          Our core team wouldn't take on a project like that without very good reasons. I'm just happy that eopkg works well enough to keep us all in business until Sol can be released.