search

pytries / datrie

Fast, efficiently stored Trie for Python. Uses libdatrie.
http://pypi.python.org/pypi/datrie/
GNU Lesser General Public License v2.1
530 stars 88 forks source link

Python 3.8 build and fix for ld #76

Closed ashwinvis closed 4 years ago

ashwinvis commented 4 years ago

See #73

ashwinvis commented 4 years ago

To be honest this would be nothing more than a band aid. It would be better to take the approach in #69

KOLANICH commented 4 years ago

They are ignoring PRs. It is completely inacceptable. It seems that the repo needs new maintainers (or a federation of forks synchronized to each other). @c4f3a0ce, @frankier, @akloboucnik, @brunoalano, @pacahon, @ashwinvis

ashwinvis commented 4 years ago

There has to be plausible reason, who knows :man_shrugging: ! More maintainers is a good idea if the current ones are unavailable. Tagging @johanneskoester (maintainer of snakemake which depends on datrie).

frankier commented 4 years ago

It's not unacceptable. (Although I understand getting impatient.) Either wait or fork. If it's blocking you somehow, vendorise/pull from github/work around it. I'd recommend reading this for a look from the other side: https://blog.burntsushi.net/foss/

frankier commented 4 years ago

By the way if your workflow needs installing from pypi, you can always push to pypi under another package name (I know it's not great but...).

ashwinvis commented 4 years ago

I think pip install -e git+https://path/to/repo.git or pip install htttps://path/to/git-tagged-release.zip is a better option rather than adding noise to PyPI. Certainly not optimal, just duplication of effort.

KOLANICH commented 4 years ago

It's not unacceptable.

It is. It is disrespect to everyone sending PRs to ignore them. If they don't maintain the project, they should archive it to make it clear that PRs are not accepted and that we shouldn't expect anything.

The only reasonable exclusions are forces majeure like death, hospitalization, disablement, loss of sanity, inprisonment, hardware failure, war. But I saw at least 1 commit since I have sent my PR. This is not a commit reporting of project being closed. It Is just a regular commit. This just means that the maintainers don't respect us.

about burntsushi's blog post:

So what does this have to do with FOSS? The key, for me anyway, was being able to put up a boundary between myself and unattended issues and pull requests. I had to find a way to say to myself: “I am volunteering my time and it is okay if I don't respond in a timely manner. I trust that most other people will understand this and be reasonable about it.”

It is OK to ignore issues, because issues is when someone wants you to do something for him for free. If the issue is really severe one who really need it to be solved the most will implement and send a PR.

PRs is another situation. Someone has done something probably valuable for your project for free and expects you to merge it fast. It is just disrespect to ignore that. Especially if the patch is a few lines of non-complex code and can be merged by hitting a single button on GitHub.

By the way if your workflow needs installing from pypi, you can always push to pypi under another package name (I know it's not great but...).

I usually use PEP 508 to specify direct links to dependencies.

Artoria2e5 commented 4 years ago

You can maybe update the CI file to test 3.8 too, or even better just test nightly so we know what will break in the future. (people are asking for a key pointing to the latest stable at travis-ci/travis-ci#9180, but i don't think they are doing it anytime soon.)

ashwinvis commented 4 years ago

Done. Ideally I would get rid of Python 2 support also, but I would rather let the maintainers do it.

johanneskoester commented 4 years ago

@ashwinvis do you see a chance for this to end up in a release sooner or later?

ashwinvis commented 4 years ago

I am not the maintainer, just a humble user of Snakemake... I would urge you to send an email to the datrie maintainers and resolve this deadlock

tacaswell commented 4 years ago

@KOLANICH Your comments here are out of line.

Someone has done something probably valuable for your project for free and expects you to merge it fast. It is just disrespect to ignore that.

I'm sorry you have this expectation, but that is not the reality (I suggest reading https://snarky.ca/setting-expectations-for-open-source-participation/ for more context). Your comments are far more disrespectful.

ashwinvis commented 4 years ago

I agree, @KOLANICH's remarks could have been spelled out better, but there is no denying that the maintainers are active on GitHub, yet they choose to ignore all these PRs for several months now. It is a completely unnecessary trouble for all to start with.

tacaswell commented 4 years ago

These commits were merged in #80 . Thank you @ashwinvis