Who is core team packages? And where are the docs? This needs a Wiki. about chocolatey-packages HOT 55 CLOSED

@Redsandro We are working on creating some documentation for this repo. TomOne actually sent me an email about this last night, that I have to review. Our intention is to get this onto the wiki here as soon as possible.

All of the points that you have made are valid, and exactly what we have been discussing via email.

from chocolatey-packages.

I put together some contributing guidelines.

from chocolatey-packages.

Nice. And nice hint on the AutoHotKey vs AutoIt info!

But Package Icons: Why so complicated? This is one guideline I am planning to ignore, because in my lousy opinion, it doesn't make enough sense to justify the hassle.

from chocolatey-packages.

This is one guideline I am planning to ignore, because in my lousy opinion, it doesn't make enough sense to justify the hassle.

What exactly is complicated here? Genuine question?

The need for an icon is really about perceived quality of the package, and it's contents. While browsing through the packages list, it is easier for people to identify the icon that they are interested in, so it really makes sense to have one. While it is not mandatory for a package to have an icon just now in order to get through moderation, I think there will come a time when it is required.

from chocolatey-packages.

The need for an icon is really about perceived quality of the package, and it's contents.

I absolutely agree and that's not what I'm contesting. I could even imagine I was the first one who ever sent a maintainer a request to add an icon. I've always been fighting to improve perceived quality.

But something else I'm very passionate about is unjustifiable hassle. Time is precious. We all got a lot to do. Let's not waste it by jumping through hoops.

For example, imagine we have our package almost complete, cursor in the icon tag in the nuspec editor, browser open with the image of a logo loaded.

Here is the guideline

• Right click image
• Save as
• c:\path\to\project\icons\file.png enter
• Go to https://github.com/chocolatey/chocolatey-coreteampackages/wiki/Contributing%20guidelines#package-icons
• copy/paste long icon url
• alt+tab to nuspec editor
• paste URL
• Change {{PackageID}} and {{FileExtension}}
• [win] cmd [enter]
• cd c:\path\to\project\ enter
• git add -A
• git commit -am "Need the gawddawm commit hash is all"
• git push origin
• Alt tab to browser
• Go to github
• Go to forked repository
• Create and submit pull request
• alt tab back to cmd
• git status
• copy commit hash
• alt+tab to nuspec editor
• Change {{commitHash}}
• Save, ready for cpack or commit
• Note that package is broken until pull request is accepted.

Here is what I do

• Right click image
• Rehost image (using for example imgur extension or whatever you prefer)
• Alt + D, Ctrl + C, Alt + Tab, Ctrl + V
• Save, ready for cpack or commit

I mean, feel free to invent something that's quicker and easier than this one. I'm even willing to do a few more keystrokes. But the proposed method is wayyy too much hassle, in my lousy opinion.

github vs imgur

I know someone is gonna say "but imgur has no promise to host the images forever!"

Well, this is true. But does github? Here's a fact: Github has changed urls suddenly in the past. Imgur never did that. Github sometimes stops hosting on certain urls for bandwith reasons. In my history with Chocolatey, I've seen github-hosted icons temporarily go 404 for up to a day. I have never seen imgur done that yet.

So, statistically and hassle-wise, my solution wins. That's what I meant.

If there is a good reason to want it this way, you should probably figure out a way to:

1. Automate this
2. Drop the hash requirement

from chocolatey-packages.

I know someone is gonna say "but imgur has no promise to host the images forever!"

I think imgur is worse than cdn.rawgit.com. Imgur deletes images after some time when there are no requests. That’s really bad and will lead to 404 for the affected packages. You wrote that yourself here: https://github.com/chocolatey/chocolatey.org/issues/53#issuecomment-27441182 .Therefore I’d use cdn.rawgit.com. Keep in mind that cdn.rawgit.com is not the same as GitHub raw links, so don’t confuse them. 😃

Well, this is true. But does github? Here's a fact: Github has changed urls suddenly in the past.

As far as I noticed, that is not the reason for the 404s. GitHub redirects old link formats to new one. The reason for 404s is that some maintainers change the location of the file (e.g changing the folder structure in the repository or renaming the repository). That’s exactly because we use cdn.rawgit.com, because files there are cached permanently, which means that there cannot be 404s. Of course that means that one a link is set up, it won’t notice updated icons for the same link. That’s why the commit hashes come into play – to be able to update icons.

If there is a good reason to want it this way, you should probably figure out a way to:

1 . Automate this

Good idea

1. Drop the hash requirement

Then we would loose the ability to update icons as explained above.

from chocolatey-packages.

Then we would loose the ability to update icons as explained above.

Ah now I get it! You mean "lose the ability to retain icons of old packages." That makes sense in certain use cases. Although imo not important enough to make people jump through so many hoops (you want people to 'donate' their most important packages to the core repo so they will always be uptodate and add value to chocolatey). I would keep getting an icon easy. Making it compulsory is already a big step forward. But apart from that, I bet there could be some magic that copies and stores this icon with the package. Or something.

from chocolatey-packages.

There is a lot to be said for keeping the icon with the source of the package, i.e. in the same GitHub repo. Putting it on something like imgur means that there is a disconnect between the main portions of the package, so personally I think keeping them in the same Github repo is the way to go. With that being said, using the raw links is what has been found to be the best solution to this. Although there are a couple extra steps to go through, I personally think we are getting the best of everything.

from chocolatey-packages.

(I am dramatizing a bit in my response):

But the worst in terms of ease, in terms of welcoming new contributions, the worst in making it easy for people, the worst in todays trend of making complex stuff easy. Knowing how easy google contacts works on all devices, and tried setting up a Funambol server to do the same on Maemo, it quickly becomes apparent how certain things provoke an "oh nevermind then" mentality.

I am the first who will say icons should be mandatory. But if we go from how it was (packages don't need icons, easy) to a 22-step workflow when a 3-step workflow also works, we are not persuading anyone to transfer the packages they so poorly update.

I am saying this is too much hassle for what it's worth, and I am one of the bigger nerds in the pool. If this goes from recommendation to policy, expect more people to abandon their packages rather than transfer them to the core packages team. Which is the opposite of what we want.

I recommend relaxing the icon guidelines and use this transition period to figure out a way to automate this.

from chocolatey-packages.

An image is nice. My thoughts are mostly that I don't care where it came from. Ultimately I want to have chocolatey.org suck up the location and save it off. That way all images are served from chocolatey.org so you don't get the messages with HTTPS that some things are not encrypted. Moreover that it is all coming from chocolatey.org so there isn't a question on trust.

from chocolatey-packages.

Ultimately I want to have chocolatey.org suck up the location and save it off.

Details on why it doesn't do this already - we have hosting provided generously by AppHarbor, which is like Heroku. Nothing persists between pushes aside from database and files off somewhere else.

from chocolatey-packages.

Ultimately I want to have chocolatey.org suck up the location and save it off.

Yes, this makes a lot of sense to me. Would this be on a per version basis? i.e. check the bytes of the image, if they are different, store it somewhere different, so older packages can still reference the old image, and newer ones use the new one?

from chocolatey-packages.

Dumb question, why would you ever want the older one?

from chocolatey-packages.

I'm sure there are some use cases for it, but I've been toying with the idea for almost six months and can't come up with a really good reason on that one

from chocolatey-packages.

This is one of those rare cases where we agree. 😉

from chocolatey-packages.

I'm sure there are cases where the icon is heavily branded or stylized and could change dramatically for some new major release.

from chocolatey-packages.

Dumb question, why would you ever want the older one?

The main use case, that I can see, is when looking at the gallery and looking at older versions of the application, for the same reason that you want the icon in the first place, you would want the icon in the gallery to reflect what the icon was for that version of the application.

Granted, as edge case, but IMO a valid one.

from chocolatey-packages.

in @gep13's defense, although I'm personally not interested in older versions, it is true that some pieces of software have a distinct icon for certain versions.

So in my opinion, it is a valid edge case, not worth making it harder for people to commit, but not completely useless either if you manage to automate this.

from chocolatey-packages.

What do we use on versions that had no icon?

from chocolatey-packages.

What do we use on versions that had no icon?

Right now, I personally think the default icon isn't very nice to look at. I would say simply that no icon is shown, or a more generic Chocolatey Icon is used.

from chocolatey-packages.

Agreed on the default. Let's do something crazy with the default icon!

from chocolatey-packages.

💩

from chocolatey-packages.

💩

I like your thinking, but no 😃

from chocolatey-packages.

Also a no from me. :)

from chocolatey-packages.

There are a lot of iconless command line tools.
We could have a couple of default icons that switch based on the presence of certain tags/keywords.

from chocolatey-packages.

from chocolatey-packages.

PS - This is just chocolate pudding.

-edit-
Sorry, it's monday.

from chocolatey-packages.

I'm not particularly interested in (icons of) old versions, but since the team urges me to go the extra mini-mile, I feel like adding my second two cents. If we do this, if we care about not using services like imgur, let's do this properly.

I'm not sure depending on GitHub's CDN for old icon versions is a sturdy solution. If we lose GitHub or their CDN, or if we want to cater to countries like Russia, India and China (where GitHub is blocked off and on), it will be a tedious task to rebuild the history of icons for each package, and it would require manual labor to make these icons available on some other CDN. It's better to have full the icon history available in a file (version) tree in HEAD. This would make the icon base more sturdy and portable.

from chocolatey-packages.

I would like to know who has access to the ketarin machine.
What needs to be done from a pullrequest to having the package aumatically updated through chocolatey?

We need someone with that power to take a few moments to look over the pending PR's and merge/fix/add them.

• Tixati (15 minutes ago)
• AEMEI partition wizard (2 months ago)
• Resource Hacker (3 months ago)
• Absolute Uninstaller (4 months ago)
• RenameMaster (5 months ago)
• vcredist2015 (5 months ago)
• UltraDefrag (7 months ago)
• patch-my-pc (8 months ago)

Also see this discussion. This is becoming a problem because no one (including new users) is motivated to make fixes anymore if they are never merged.

from chocolatey-packages.

Currently, me, Rob and Tom have access to this machine, but we can certainly have a chat about opening this up to a wider group.

@ferventcoder do you have a script for auto importing xml files into ketatin on each execution, so as to ensure most up to date configuration after the pull?

Sent from my Windows Phone

From: Sander AKA Redsandromailto:[email protected]
Sent: ‎16/‎10/‎2015 20:30
To: chocolatey/chocolatey-coreteampackagesmailto:[email protected]
Cc: Gary Ewan Parkmailto:[email protected]
Subject: Re: [chocolatey-coreteampackages] Who is core team packages? And where are the docs? This needs a Wiki. (#20)

I would like to know who has access to the ketarin machine.
What needs to be done from a pullrequest to having the package aumatically updated through chocolatey?

We need someone with that power to take a few moments to look over the pending PR's and merge/fix/add them.

• Tixati (15 minutes ago)
• AEMEI partition wizard (2 months ago)
• Resource Hacker (3 months ago)
• Absolute Uninstaller (4 months ago)
• RenameMaster (5 months ago)
• vcredist2015 (5 months ago)
• UltraDefrag (7 months ago)
• patch-my-pc (8 months ago)

Also see this discussion. This is becoming a problem because no one (including new users) is motivated to make fixes anymore if they are never merged.

Reply to this email directly or view it on GitHub:
#20 (comment)

from chocolatey-packages.

@gep13 can you tell me the exact code the ketarin machine uses for all the batch jobs?
And where do you put this global code in stead of per-package code?

from chocolatey-packages.

@Redsandro sorry, I am not clear on what you are asking for. Are you talking about the scheduled task that is running on the ketarin machine to execute ketarin every hour?

from chocolatey-packages.

@gep13 Yes - I think.

You or @TomOne told me that in this repository, Ketarin package settings need not include execution commands. There is a one size fits all global command, and I'm guessing that it goes in the global settings:

It's probably documented somewhere, but I cannot find it.

I'm looking for that command.

from chocolatey-packages.

Ah, I see what you are getting at. 😸

Yes, on the Ketarin instance, there is a global execute command that runs for all packages that are contained within the Ketarin instance.

This is the command:

chocopkgup /p "{appname}" /v "{version}" /u "{preupdate-url}" /u64 "{url64}" /pp "{file}"

from chocolatey-packages.

@gep13 Really? It uses the preupdate-url? That's always the one in the URL field in the download source, right? So if we need to regex, we need to regex a variable and put that variable in the URL field?

from chocolatey-packages.

And every hour, we run this command:

C:\Windows\System32\cmd.exe /c %ChocolateyBinRoot%\ketarinupdate.cmd

which contains:

@echo off

For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c%%a%%b)
For /f "tokens=1-2 delims=/:" %%a in ("%TIME%") do (set mytime=%%a%%b)

echo Updating the github repo first
pushd C:\github\chocolatey-coreteampackages\automatic
call git add .
::call git commit -m "updates prior to automatic run for %mydate%_%mytime%"
call git reset --hard HEAD
call git fetch && git rebase origin/master
::call git push origin master
popd

echo Calling ketarin now the the repo has been updated
call "Ketarin.exe" /silent /log=C:\ProgramData\chocolateypackageupdater\ketarin.%mydate%_%mytime%.log

from chocolatey-packages.

@Redsandro said...
Really? It uses the preupdate-url? That's always the one in the URL field in the download source, right? So if we need to regex, we need to regex a variable and put that variable in the URL field?

Sorry, I am not exactly clear on what you are referring to. Can you elaborate? This might not be the optimal way of doing this. Perhaps @TomOne or @dtgm might be able to help with this.

This is the way that this Ketarin machine has been set up for almost two years.

from chocolatey-packages.

@gep13 thank you for pointing the commands out. Now I get what's going on. 😄

As for the "preupdate-url", I mean that the url is actually not a value called url (like url64 is a value called url64, but rather the contents of the download url field in the ketarin package settings. This is a bit misleasing and I never understood this until just now.

from chocolatey-packages.

@Redsandro said...
This is a bit misleasing and I never understood this until just now.

Ok, cool, sounds like everything is in order then, right?

from chocolatey-packages.

Yes, all is clear!

from chocolatey-packages.

I know who have access to the ketarin machine now. I think this issue can be closed.

from chocolatey-packages.

I do have a script that auto updates ketarin by importing all ketarin scripts in a particular directory. So I only have to merge.

from chocolatey-packages.

@ferventcoder do you have a link to that script, so that we can put that on the Ketarin machine? Thanks!

from chocolatey-packages.

Should implement some sanity checking.

How are (previously working) broken packages detected now?

Does ketarin do something like info>stdout error>stderr? It would be nice to pipe the output log of only the errors to some website where we can see packages that need fixing.

from chocolatey-packages.

Does ketarin do something like info>stdout error>stderr? It would be nice to pipe the output log of only the errors to some website where we can see packages that need fixing.

Not as far as I'm aware.

from chocolatey-packages.

@gep13 the script is at https://github.com/ferventcoder/chocolatey-packages. I'm starting you there so you can see that all of the ketarin.xml files have been extracted to a singular folder, like @dtgm has done. Then inside of there is a files directory that contains this gem - https://github.com/ferventcoder/chocolatey-packages/blob/master/ketarin/files/ketarinupdate.cmd

The version of ketarin needs to be the latest or it will stay open after import.

from chocolatey-packages.

@ferventcoder perfect thanks, I will take a look, and let you know if I run into any problems. Cheers!

from chocolatey-packages.

@gep13 the really nice thing about this script is that I can set it on a new machine and it will import all of the jobs into ketarin.

from chocolatey-packages.

@ferventcoder agreed. That has always been my concern about the "portability" of the current ketarin machine we are using.

from chocolatey-packages.

@gep13 We don't even have to change the structure.

iirc you can look one level deep in subfolders using FOR /D %%F IN *, or recursively through all folders (probably some overhead because of all the tools directories) using FOR /R.

from chocolatey-packages.

@Redsandro although we "might" be able to do something, I think there is something to be said for consistency. If this is what both @ferventcoder and @dtgm have opted for, I think we should follow their lead.

from chocolatey-packages.

@gep13 while I agree consistency is an important thing, I also like to point out that things like Python, ES6, HTML5 and the likes wouldn't exist if we all just went for consistency rather than improvement.

The best approach to any kind of package - for clarity, portability and maintainability's sake - is always to have it as self-contained as possible.

For that reason, the fact that we chose to separate icons from packages in their own icons directory is something of a bad decision in that regard.

If we now introduce a third location we need to take into account for package maintenance, we're just going against common sense.

Just my two cents. I will play along either way.

from chocolatey-packages.

More of keeping the ketarin.xml file away from the autopackage so it doesn't get sucked up by the generating tool. But that can be addressed in other ways.

from chocolatey-packages.

And for the sake of argument that the ketarin bit isn't really part of the package - which is a fallacy, it is part of what builds the package.

from chocolatey-packages.

.gitignore, Gruntfile.js, thumbs.db GMTA 😉

from chocolatey-packages.