Discussion continued from #64

[zmwangx]

No description provided.

[zmwangx]

@jarun

I came across Chocolatey earlier. Not sure how popular it is yet.

AFAIK, if there's a popular package manager on Windows, it's Chocolatey. However, I also once heard that Windows 10 would come with a package manager (and never heard anything about it again, just like many things Windows. Might have been a flop, who knows).

We have a limit on keeping issues alive, remember?

Well, I think that's a limit on unconfirmed bug reports. There's no reason to close confirmed-yet-not-fixed-in-15-days bugs and good feature requests; closing those just defeats the purpose of an issue tracker.

I would like to add a deb package.

It's not hard but pretty annoying to create a deb package. Check out my new branch https://github.com/zmwangx/googler/blob/build-deb. My makedeb scripts automatically builds a deb package from any commit/tag and put it in dist/ (technically any commit or tag, but realistically only commits after patching Makefile — patch in aeebea8 from the same branch). You may give it a spin on a Ubuntu/Debian system with the appropriate dependencies installed (listed at the top of makedeb).

BTW, does GitHub have any way to integrate generation of deb packages?

Travis can submit build artifects to GitHub releases. See https://docs.travis-ci.com/user/deployment/releases. That feature has been in place for years, and it's very neat. The only problem is securing the GitHub token, which can be achieved through https://docs.travis-ci.com/user/encryption-keys/. IIRC Travis's Ruby client does that for you automagically.

@shaggytwodope Feel free to chime in.

[jarun]

One more thing:
Is it possible to check if the file googler has any changes after triggering travis? In case travis doesn't have any info of commit changes, how about, cloning the repo (git clone --depth2) and checking using git diff if the file googler has changed?
The idea is to pass the build without actually running any tests if the file googler has no changes.

[zmwangx]

I wouldn't say it's impossible, but it should be very hard. The problem is you don't know how many commits are new since last build.

[jarun]

git diff --name-only HEAD^ HEAD wouldn't work?

[zmwangx]

When you build on the master branch: you could have pushed several commits at once, and Travis will run a single build. You don't know where the last build was on.

When you build on another branch: initial commit needs to be diffed against its common ancestor with the master branch, and all further commits suffer from the same problem as above.

When you build on a PR branch: you probably always want to diff against the common ancestor with master.

[jarun]

Got it. We'll stick to [ci skip].

[zmwangx]

On second thought test skipping is indeed a worthy feature. Submitted #66.

[jarun]

I couldn't access the build-deb. Also, as @shaggytwodope confirmed, he would be looking into the .deb creation stuff. I'ld let him have it his way. For our case, we need a noarch package that (if possible) works on all Ubuntu/Debian systems.

[zmwangx]

Wrong link, I happened to submitted #67 just a moment ago.

[jarun]

Also I'm checking if we can support DuckDuckGo:
https://www.reddit.com/r/linux/comments/4grb3t/help_improve_duckduckgos_linuxrelated_searches/d2lpvyb

[jarun]

Wrong link, I happened to submitted #67 just a moment ago.

👍

[zmwangx]

Re DDG: It would be nice (for the paranoid...), but I imagine it would be at least 70% the work of rewriting "ddger" from scratch 😉 For instance, DDG News is so different, at a glance it would be very hard to fit into the existing framework.

[zmwangx]

By the way, here's a more realistic goal: what about a CHANGELOG file? This way users don't have to go to GitHub releases to find out what's new, especially when they upgrade from a package manager. (Homebrew, for instance, automatically grabs the CHANGELOG file from a tarball, so there's zero cost to supporting that.)

[zmwangx]

Also, I have another idea about a TODO list. Rather than having a file, what about one dedicated issue with a rolling checklist? This way the editing cost is extremely low (don't need to waste commits on more non-substantial changes), and we can link to the checklist from README, something like

Want to help out? Check out our TODO list at #xxx.

[jarun]

it would be at least 70% the work of rewriting "ddger" from scratch

I am fine with that... if it demands a new project. I am semi-paranoid myself and DDG is pretty nice. The current problem is: you wouldn't see the search result data in DDG page source. There's nothing to parse the results. So let's want for a reply.

By the way, here's a more realistic goal: what about a CHANGELOG file?

Do we put the same info that we do in release notes? I myself can't add everything and maintain 2 files with different contents on every release. So it has to be the same highlights.

Also, I have another idea about a TODO list.

👍

[zmwangx]

Do we put the same info that we do in release notes?

Why not?

[zmwangx]

you wouldn't see the search result data in DDG page source.

That sucks. And their API is not a search API. Good luck reverse engineering minimized JavaScript: https://duckduckgo.com/d1904.js and https://duckduckgo.com/g1404.js.

[jarun]

Why not?

Because I skip changes which should not be of interest to users. I thought we might want to maintain them in Changelog.

Good luck reverse engineering minimized JavaScript

I know and I'm not going to reverse engineer that stuff. Tapped them to check if there's anything better they can provide.

[jarun]

Ahh OK. It does get picked by package managers. I reverted my earlier comment.

[zmwangx]

I think this thread has served its purpose. TODO list in #69.

[zmwangx]

Because I skip changes which should not be of interest to users. I thought we might want to maintain them in Changelog.

I missed this bit. I would say no, implementation details need not show up in changelog. Use git-blame for that...

[0fiscalentropy]

Regarding potential support for DDG, would using its /lite interface be easier?

[jarun]

googler will never support DDG. Please see my other project ddgr. However, I stopped working on it because I didn't get any help (read response) from the DDG team despite multiple attempts. PRs are welcome.

[zmwangx]

I'm locking this conversation because it was pretty much a chat thread without a central topic. Adding more stuff to it only makes it worse for discoverability. If you want to discuss a specific point mentioned here, please open a new issue with an appropriate title.

@jarun Feel free to unlock if you don't like locking topics.