lark vs. lark-parser

[wiene]

The lark name clash between

https://github.com/lark-parser/lark

and

https://github.com/voidfiles/lark

is currently causing some discussion inside Debian (see https://bugs.debian.org/941657#42 and the following message in that bug). There is no straightforward way to package both for Debian (see also the reference in my last sentence for details). Currently none of those two are included in Debian but there are plans to package your software for Debian. While there are - as far as I know - no plans to include the second at present, it would be nice to keep the door open to include both in Debian.

It also seems that this name similarity caused trouble for users of other projects (see e. g. hpc/charliecloud#494).

For PyPI you seem to have solved this name clash by using lark-parser as name. Do you think it might be good (at least in the long run) to consistently rename lark throughout the code (although this would be a disruptive change)?

[erezsh]

Thank you for allowing me to weigh in on this.

I think it's fair to assume that the other lark project is a dead project,

You already mentioned how it hasn't been updated in 6 years. In fact, its whole life-time was just shy of two weeks, between its first commit and last commit. (see here: https://github.com/voidfiles/lark/commits/master)

That is very problematic for a web project. In web, the entire tech stack changes every two years.

In fact, there are already many newer and more popular projects nowadays, that provide exactly what it provides, and much more.

Additionally, github's new and useful "Used By" feature reveals not a single popular repository uses the other lark. As for my Lark: It's actively maintained, and still gaining popularity. It's not even three years old, and it's used by 15 times more packages, several of which, each on their own, have more stars than the other lark. They will all be very inconvenienced if I change my import name.

In conclusion: That Lark is pining for the fjords. It is an ex-lark. If you haven't added it yet, chances are you never will.

Of course, I'm biased, but I think the reasonable choice is to add my package as-is.

[wiene]

@erezsh: Thanks for sharing your thoughts on this. You might be right that the problem that it is not easily possible to package both larks for Debian is rather a hypothetical than a real problem given the history of the other lark project.

Still I think that it is unfortunate to have two different projects using the same or similar names since this might confuse people as the above example shows. This danger will persist at least as long as both codes are available - even if one project is dead.

On the other hand I can perfectly understand your concerns to introduce such a breaking change - in particular since there are many dependent projects that could be upset by such a move.

[erezsh]

l can see that neither choice is optimal. I hope you will choose the lesser of the two evils, whatever that is, in your eyes.

If you don't mind, I'll appreciate if you'll keep me posted on which course of action you chose. And if there's anything I can do to help, that isn't changing the import name, please let me know.

Happy new year!

[wiene]

If you don't mind, I'll appreciate if you'll keep me posted on which course of action you chose.

Lark was accepted for inclusion in Debian on 2020-01-13 (see Debian package tracker).

[erezsh]

Thanks, that's great to hear.

[MegaIng]

@wiene In case it is still relevant, pip install lark is now possible: #712 (and the other package is no longer on pypi)

[wiene]

@wiene In case it is still relevant, pip install lark is now possible: #712 (and the other package is no longer on pypi)

Thanks for letting me know. This goes well with the Debian package name. :-)