CocoMUD client

Simply put: there are none yet. And CocoMUD uses a lot of dependencies. I've worked on this documentation. So I'll put it here as a memo, it should be added in its own documentation:

• First get Python 3.6 (or later, 3.6 is the minimum requirement now).
• The easier is to run pip (within a virtualenv or not) :
  

      > cd src
      > pip install -r requirements.txt
      

• Next you should be able to simply:

  python cocomud.py

Commands are to be adapted depending on the operating system. This is the very short version, don't hesitate to ask in case of errors or doubts.

What do you think about replacing the requirements model by a pipfile?

HMM...

I cann't find the requirements file.

I have to admit I'm not familiar with other formats (I used a requirements.txt file just because I knew it, so I'm willing to use a different strategy of course).

The i128 branch was merged into master only an hour ago or perhaps less, check that you've fetched the last revisions from master. Also note that i128 was the first version to be ported to Python 3 and bug might still subsist (CoccoMUD ran on Python 2.7 until the issue #128 was addressed).

Hello,

I got an error when importing the accesspanel class. I don't know if I have all dependencies...

I pulled all changes from upstream master but I didn't found the requirements file.

Cheers,

I'm really sorry, I had forgotten to add the accesspanel. It's a dependency I worked on for some time, thinking it could be useful for others, but it's not flexible enough to be used anywhere but in CocoMUD and perhaps my little chat client. I added the accesspanel in CocoMUD, and the requirement file that I had forgotten to add as well. I double-checked this time, you should find both when pulling from Github.

Hello,

I discovered that building inside a virtualenv causes problems with python-redmine and distutils. I don't know what causes the problem, however.

If you try to build it outside a virtualenv it runs well and without problems.

Cheers,

Yes, that's what I noticed too. On my computer, it's `zope` that breaks due to the missing `__init__.py` file, though it shouldn't matter in Python 3.6. I could write a patch for that but it wouldn't be pretty. I'm still wondering whether anyone but me will build it (I mean, if you contribute to the code, do you just run from source or want to build it)? If anyone else want to build and keep the virtualenv I'll have to come up with a patch, some kind of brut-install of distutils, zope and the other missing libraries.

Hello,

I've added this to setup.py under packages entry:

+ "namespace_packages": ["zope.interface"],

Ope this helps.

Thanks, it did help. Now it's distutils that complain. The reason can be found in this post . In short, distutils in a virtual environment is shortened (you can open your pyenv/lib/distutils to see). And cx_Freeze doesn't import from the system distutils, which confuses the final executable.

And the only workaround is to build from outside a virtual environment, which is extremely annoying considering how useful the tool is, and how many dependencies CocoMUD uses.

There's a ugly hack though: copy distutils (the compiled Python file) from the system itself and paste it into the final frozen libs. That can be done automatically. It's just not very pretty.

Okay, I just pushed a commit to fix this issue. After pulling 3da5f37f8461ae41df2ffea0922133f0582da44e, you can now:

pipenv run python setup.py build

The hack was found on Github. It's almost as ugly as I would have implemented it but leaves us almost free to enjoy no matter the platform. I still believe this should be fixed in cx_Freeze itself though.