Sublime Forum

Package Control: A full-featured package manager

#25

Sounds good to me. I never know whether the forks are going to be new/untested stuff waiting for an eventual pull request or an actual more actively developed version.

0 Likes

#26

The main reason I haven’t added a repo for SublimeLint is that I was unable to tell which is the most actively developed and “best.” If there is a general best choice, or a maintain volunteers their version, I’ll add one.

0 Likes

#27

After using them both I think the original is just that, and the fork is sort of a + version if you will. They are both actively maintained, I just believe the original is complete in the author’s eyes where as some other people wanted more functionality that the original author wasn’t interested in incorporating.

The original has Python, PHP, Perl and Ruby support where as the fork has added support for JS and Objective-J as well as PEP8 checking for Python.

Which you grab depends on what you’re looking for. Personally I use the fork as I like the PEP8 and JS support.

0 Likes

#28

The Kronuz fork is more active. What is involved in volunteering a version for inclusion?

0 Likes

#29

Just someone indicating they use it and that is seems to be the best and most actively developed version. From the conversation that has happened here is appears that the Kronuz fork is most actively developed, so I’ll add it to the master channel list.

0 Likes

#30

Version 1.1.0 of Package Control was just released for upgrade. Changes include:

  • Support for local Git and Hg repositories in addition to zip/.sublime-package downloads

  • Fixed Discover Packages command to pull the proper URL from custom repositories

  • Improved the handling of upgrades and removal on Windows, reducing the number of Access Denied errors

  • Changed the downloaders to try multiple times on timeout since GitHub and BitBucket requests seem to fail fairly frequently

  • Package upgrades now copy the complete old version to the Backups folder that is a sibling of the Packages directory

  • Fixed the text of the activity indicator during individual package upgrades

Also, the master channel list has been updated to include github.com/Kronuz/SublimeLint.

Thanks for all of the feedback and suggestions, keep them coming!

@sublimator

I very much apologize for causing you to lose work with Upgrade All Packages. This new version should prevent such loss, and should also make it possible for less network-intensive updates via git and hg.

0 Likes

#31

That’s kind of messed up, but whatever I guess.

0 Likes

#32

[quote=“Anomareh”]

That’s kind of messed up, but whatever I guess.[/quote]

I’m certainly open to improving this process. What about the current process do think is messed up?

0 Likes

#33

One person saying something and acting on it without the repos in question even being looked at.

For one, the Kronuz fork should probably be the aparajita fork at this point as the last month worth of commits have pretty much just been merging his pull requests. Secondly, that fork probably shouldn’t be a fork anymore.

Also I’m not really sure what conversation happened that would affirm the Kronuz fork was the one to go with. aparajita said twice that it was the most actively developed, two people said they weren’t using it or sure about what it actually was, and I gave my impression.

Just seemed rather hasty to me.

0 Likes

#34

[quote=“Anomareh”]

One person saying something and acting on it without the repos in question even being looked at.

For one, the Kronuz fork should probably be the aparajita fork at this point as the last month worth of commits have pretty much just been merging his pull requests. Secondly, that fork probably shouldn’t be a fork anymore.

Also I’m not really sure what conversation happened that would affirm the Kronuz fork was the one to go with. aparajita said twice that it was the most actively developed, two people said they weren’t using it or sure about what it actually was, and I gave my impression.

Just seemed rather hasty to me.[/quote]

Point taken, I’ll be sure to be slower before adding repositories that have more than one copy. I did spend a little bit of time looking at the various forks before I added it and also checked out github.com/lunixbochs/sublimelint/network. I also weighed in your and aparajita’s comments. That said, I do think you have a valid point and appreciate you speaking up.

Due to the way that the versioning in Package Control is done, it is actually possible to switch the repository being used for a package at any given time as long as it was pushed after the date the previous repository was pushed.

0 Likes

#35

The only reason I really took issue with it is I know what it’s like to want the light version of something and ending up having to go digging around for it. This happens to be one of the occasions that I actually want the heavier version but many a time have I had to either pull apart something to rip off all the stuff I don’t want or go looking for the version where someone has already done it for me.

Personally, I think the ideal solution would be making both versions available, ideally with the fork being split into a new package entirely (SublimeLint+ or something) or being made available as a dev release.

0 Likes

#36

That is potentially a good idea for the next version. Right now it is not possible to map the names of individual repositories, just all repositories of a specific name. If I add the ability to map names on a per repository basis, then it would be possible to have both without any changes to the repositories.

Perhaps a better idea that would be clearer to users would be for the fork to rename itself. This would obviously require buy-in by the developer.

It is possible right now to add your own custom repositories to allow someone to use the original, but this doesn’t help solve the discoverability problem for people. It would, however, allow for easy updating.

0 Likes

#37

My sincere apologies to everyone. I was only looking at the commit histories to see which had been more active recently – whether or not those commits were from me.

Probably not. I haven’t looked closely to see what the essential differences are between the forks. Ultimately it would be nice if the forks could be unified somehow.

0 Likes

#38

If that’s true, I’ll switch! :smile:

What do you mean by “less noisy” and “less quirks”?

0 Likes

#39

Great work, thank you for making this available.

I want to submit a new package for inclusion in the package repo, how do I go about it?

0 Likes

#40

Heh, you already are :stuck_out_tongue: You’ve been the only one pushing commits to the fork for the past month. Only difference is you’re sending pull requests instead of just committing.

I don’t think this is possible. Although they seem very similar on paper, internally they are rather different. The original is much stabler and snappier. With the fork everything config wise is quite different.

0 Likes

#41

You can either send a pull request via github or bitbucket, or email me at viewtopic.php?f=5&t=2746#p12731.

0 Likes

#42

If the original is much stabler, then I will definitely give it a try and port my stuff to that.

0 Likes

#43

Agreed. Kronuz’s fork also has PEP8 checking built-in, which I don’t necessarily want all the time.

0 Likes

#44

This is unbelievable! Just what I’ve been looking for, and will be a massive quality of life improvement :smiley:

Purchasing the SFTP package just to support your work!

0 Likes