Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

What to do about melpa? #9

Open
seanfarley opened this Issue Jan 22, 2019 · 15 comments

Comments

Projects
None yet
8 participants
@seanfarley
Copy link
Contributor

seanfarley commented Jan 22, 2019

It seems that the ms-python package beat this one to the punch for being listed on melpa.

What should we do? Merge the two? Just list both? 馃

@seanfarley

This comment has been minimized.

Copy link
Contributor Author

seanfarley commented Jan 22, 2019

Since @cpbotha originally wrote the code, I wonder if he has any thoughts on the matter?

@cpbotha

This comment has been minimized.

Copy link
Contributor

cpbotha commented Jan 23, 2019

Looking at the commit log, @xhcoding started his package on November 23 with code from my blog post. (I just noticed his readme does link back to my blog post, quite prominently. :)

Anyways, @andrew-christianson started this package on November 27, a few days later. We did not see that there already was a package, else we could have joined forces.

The most logical thing to do would be to compare functionality, and ensure that the union of the two packages is on melpa so that Emacs users get the best solution available. If @xhcoding is a responsive maintainer, I'm sure that should not be a problem.

@cormacc

This comment has been minimized.

Copy link

cormacc commented Jan 28, 2019

The ms-python package on melpa appears to be windows-only (based on a quick scan of the source, there seems to be a hard-coded dll expectation), whereas this also works on linux (and I'd imagine probably OSx too?).

Kudos on spotting/fixing the filter / nil string bug quickly by the way -- I was just about to submit a PR :)

@cpbotha

This comment has been minimized.

Copy link
Contributor

cpbotha commented Jan 28, 2019

It's not Windows-only. dotnet core builds DLLs on all platforms. :)

Its major issue is that it does not yet support the new LSP API, which this package does. I was hoping @xhcoding would pop in here for chat so we could make plans.

@cormacc

This comment has been minimized.

Copy link

cormacc commented Jan 28, 2019

Ah, that I didn't know (clearly :) )

Anyway, I've added this to the spacemacs python layer and submitted a PR. Just pulling the package from git for now.

See syl20bnr/spacemacs#11913

@xhcoding

This comment has been minimized.

Copy link

xhcoding commented Jan 30, 2019

I'm sorry for my hasty behavior.
I think merging two packages is a good solution. Maybe I can transfer my package here and update the recipe on MELPA, or we discuss other solutions together.

@cpbotha

This comment has been minimized.

Copy link
Contributor

cpbotha commented Jan 30, 2019

Hi there @xhcoding ! It's great that you want us to join efforts.

Because most of the activity seems to have congregated on this repo, my suggestion is indeed that we merge @xhcoding 's work into this repo, and then update the melpa.

@andrew-christianson and the rest, what do you think?

@andrew-christianson

This comment has been minimized.

Copy link
Owner

andrew-christianson commented Jan 30, 2019

Sounds good to me!

@xhcoding no need to apologize! I'll look through ms-python to flag anything we should merge here, and happily accept any PRs from you for those or other enhancements.

I'll also PR this to MELPA, under the current package name, if that works for everyone, as it's already linked as such from the lsp-mode README, and from @cormacc's Spacemacs PR as such.

@cpbotha I neglected to include a LICENSE when I created this repo, as I didn't see if you explicitly released (any/every)thing on your blog under a specific license. Are you ok with releasing this under GPL?

@cpbotha

This comment has been minimized.

Copy link
Contributor

cpbotha commented Jan 30, 2019

@andrew-christianson GPL sounds fine to me. (for other OSS I usually do BSD, but it looks like for Emacs packages GPL is the norm?)

@andrew-christianson

This comment has been minimized.

Copy link
Owner

andrew-christianson commented Jan 30, 2019

I'll stick with that then :)

e: by which I mean 3-clause BSD. It's compatible with GPL per FSF, so it should be fine for MELPA

@yyoncho

This comment has been minimized.

Copy link

yyoncho commented Feb 3, 2019

2 more options:

  1. I can create a project under emacs-lsp organization and give commit rights to whoever is interested to support the extension.
  2. Move the code in lsp-clients.el.
@josteink

This comment has been minimized.

Copy link

josteink commented Mar 3, 2019

Emacs has recently started flagging packages which are not GPL licensed as 鈥渋ncompatible鈥.

True or not, using anything not GPL might make life more cumbersome for users, so I advice going for GPL to cause a minimum of friction.

@cpbotha

This comment has been minimized.

Copy link
Contributor

cpbotha commented Mar 5, 2019

I'm happy with whatever license gets it onto MELPA and into Emacs users' configs. :)

@rememberYou

This comment has been minimized.

Copy link

rememberYou commented Mar 6, 2019

Thanks for creating this package, it will simplify the life of more than one developer. Do you have any idea when the package will be on MELPA?

@andrew-christianson

This comment has been minimized.

Copy link
Owner

andrew-christianson commented Mar 7, 2019

@rememberYou mepla PR: melpa: melpa/melpa#6027

@cpbotha cpbotha referenced this issue Mar 24, 2019

Open

add recipe for lsp-python-ms #6027

5 of 6 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.