Why two separate libraries for `result` and `maybe` about maybe HOT 2 CLOSED

Currently the projects are setup to be ship separately, result and rustedpy-maybe (I failed to contact the owner of 'maybe' PyPI project, so we weren't able to acquire that name).

I don't have any intention to merge the two projects as you mention, I don't think there's any need currently, but that may change in future depending on how things go. But right now, I'm going to keep the separate.

We may benefit slightly from reducing some duplicate project files if the two were merged, but given this library is not used by many people, I don't want to put in the effort doing all that work until it's absolutely necessary or someone (such as yourself perhaps) volunteers because you're actually using this library in a real project.

If anyone wants to use both result and rustedpy-maybe, they'll need to just install both. I don't want to create a single library with multiple things in it (result, maybe, plus more things in the future?). Maybe this will change in the future, but not right now.

We also have a really good name, result, but that name doesn't make sense if we put the maybe inside the same result library.

initial decision to split result and maybe into two separate repositories

There was no decision to split. Result was created back in like 2016 by the original author and this maybe library was created last year because someone asked for it. This maybe library is used by very very few people: https://pypistats.org/packages/rustedpy-maybe compared to result: https://pypistats.org/packages/result

I'm highlighting this issue because I encountered problems running pytest on this library. Specifically, rustedpy-maybe is defined as maybe under the src directory. As a result, pip install -e . doesn't work correctly since it tries to find rustedpy_maybe under src, fails to locate it, and causes conflicts

The issue you're describing isn't what I've encountered before. Here's what I did,

python -m venv venv # create a new virtualenv

source venv/bin/activate # activate the virtualenv

make install # I just added the Makefile now, see https://github.com/rustedpy/maybe/blob/master/Makefile

make test # Should work correctly

cd result
pip install -e . # now you should be able to install result in the same virtualenv as well

It could be you've got a very polluted virtualenv (or you're not using a virtualenv at all!?). Always use a virtualenv (or a virtualenv manager like Poetry), Python's dependency system isn't great and running pip without a virtualenv is going to cause problems eventually with your OS.

Run pip list to see what's installed in your virtualenv (or in your non-virtualenv environment if you're not using a virtualenv)

from maybe.

If you have any problems while working on a PR for specific issue, just post a comment there and I'll try to help.

from maybe.