Comments (5)
Yes, that sounds excellent. I'm very open to ways to better distribute this.
First, thoughts:
Having git as an option is fine, but I don't think it should be the main one. Firstly because the git repo contains a bunch of things that are irrelevant to users (the tests, the full repo history, etc), and also because it requires you to manually think about releases yourself as an end user. You probably don't want to be on master, but that is what you want to get by default if you clone the project. Instead you want to be on the latest tagged release. And on top of that, yes, being tied to git will be a bit inconvenient for some users.
We could build an install/update script without git pretty easily, because Github gives us most of the information anyway. You can easily query github for the latest release (curl -s https://api.github.com/repos/pimterry/notes/releases/latest
), get the tag (grep tag_name | ...
), and pull down the latest version of notes (curl https://cdn.rawgit.com/pimterry/notes/$TAGNAME/notes > /usr/local/bin/notes
). That might be a reasonable starting point. Need to think about what happens when the list of files to download changes. Maybe a script that downloads a manifest of files and locations first, which potentially changes per-version, and then installs what it's given.
Looks like just moving to the Bash Package Manager might get close to this.
In a perfect world, I'd like a separate distribution channel that we explicitly push releases to (potentially automatically by pushing tags to github), that contain only the files that end users actually care about (i.e. notes
and notes.bash_complation
), and which automatically handles updates by integrating with normal system updates, rather than notes
having to trigger updates separately. Proper package managers will also do things like uninstalling and prompting users for updates nicely all for us.
To do that, we'd want native per-platform packages (RPMs, DEBs, whatever you need to publish to homebrew, etc). Notably we're already published to the Arch User Repository (see #7) - that's a package that internally manages it's own updating with Git, which is a bit crazy long-term, but works for now.
Building our own packages is harder, but probably not that hard. fpm
should let us build them, and then we'd need scripts to automatically push the results to each of the relevant distributions channels.
from notes.
So, given that wall of text, where should you start. If you're interested, trying doing one of:
- Seeing what the Bash Package Manager actually gives us, what it doesn't, and how much work that might be to publish to.
- Writing an install script so that users can do something like
curl https://cdn.rawgit.com/pimterry/notes/master/install.sh | bash
and get the latest version up and running (and then do the same again later to update). Needs to think about making sure updates work, and handling later changes to the set of files we publish in releases (e.g. when zsh completion gets added), etc. - Trying to build a package for one platform (e.g. deb), working out how automated publishing would work for that kind of package, and then trying to work out a way we could easily do that automatically when we want to do a release (which we can expand to cover more platforms later).
They're approx that order of difficulty I think. Let me know if you're keen, and where you want to start.
from notes.
Great! Let me read up on each of these and see what I can do.
from notes.
I think haveing platform specific packages (deb, rpm, etc) that are integrated into the package managers (apt, packman, etc) is the right way to go, but I started looking at the documentation and I think that is a bit out of my league at the moment, even with fpm
.
bpkg would provide an easy option, but that is yet another tool to install. It would be pretty simple to add later on, but I dont think it is the way to go at the moment.
It sounds to me like the best option for right now would be a setup script to run remotly via curl. I can get to work on this and submit a PR, but I have a few questions first:
How do you want to handle updates?
Encourageforce users to stay with the newest version via background auto update?- Prompt if they want to update to the newest tagged release, or only for major version releases?
- Add an
update
command that checks and does the update?
What do you think about this update process? The notes script has code that knows how to uninstall itself and how to remotly run the setup script so that if the list of files or dependencies change it can clean itself up and invoke the new process.
from notes.
Phew, exciting. Ok. I'd rather not integrate the updating code into notes
directly, largely because it's a big can of worms, especially if you get real package managers involved too later. Even in the existing arch case for example, it seems like it's going to be really easy to accidentally end up with two independently managed install on your machine, and to not be able to track down or uninstall them again cleanly in future.
I think that rules out auto-update and active prompting for now. We should start with a simple script that just does installs of the latest version, and build everything up from there. Once we've got that in place, we can build up notifications and autoupdate on top very easily.
I'd aim to first write a script that:
- You can curl and run one command to get an immediately working
notes
setup on a clean typical machine on the latest version - You can curl and run again to update a
notes
setup on a typical machine that ran the script before to the latest version - Prompts if it's not sure what to do about anything (e.g. confirm before overwriting
/usr/local/bin/notes
) - Outputs the list of files created afterwards, for manual uninstallation (we can do nice uninstalling later)
'Typical' includes at least normal Ubuntu installs and OSX with GNU tools installed. Latest version is defined by releases on github. If there's more you want to strip out of that to keep it even simpler, feel free.
Later steps might include:
- Prompting for updates
- Doing bash (and zsh: #33) auto-completion automatic installation as part of this
- Uninstalling easily
- Installing not the latest version
- Listing changelogs and new features when you install
- Integration into proper package managers
But we don't need to worry about any of that to get a useful working first step in place, and we can then start building from there.
from notes.
Related Issues (20)
- Templates for Issues and Pull Requests.
- "notes recent" command to show recently edited notes HOT 9
- The strange case of missing note HOT 3
- exits successfully($? is 0) when it fails to create notes HOT 2
- 'notes o' says it can't get a file descriptor on Linux HOT 5
- Spelling errors in pull request template. see checklist point 3. HOT 1
- notes should ignore files in hidden directories HOT 3
- settting $NOTES_DIRECTORY does not affect program HOT 2
- Add a --version option HOT 1
- BATS fails on "Show multiple files passed by pipe from find" HOT 3
- Zsh autocompletion not working on Mac HOT 2
- Rawgit is deprecated HOT 1
- Tag support for notes HOT 3
- Notes mv HOT 4
- Append a message to note HOT 5
- Edit and save a file that is not of the default NOTES_EXT HOT 3
- Find and search do not work if notes directory is symbolic link HOT 3
- Feature request: Add post-command hook HOT 5
- Notes open does not cd to notes directory HOT 3
- Pass args to Post install script HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from notes.