Coder Social home page Coder Social logo

zdharma-continuum / zinit Goto Github PK

View Code? Open in Web Editor NEW
2.7K 22.0 121.0 12.75 MB

🌻 Flexible and fast ZSH plugin manager

License: MIT License

Makefile 0.34% Shell 99.41% Dockerfile 0.25%
zsh zinit plugin-manager zsh-configuration zsh-plugin package-manager zinit-annex

zinit's Issues

💡 Proposal: Merge all zinit-package repos into one

First and foremost: NICE.
Anyway here's me again, with another proposal.

To manage zinit packages more easily I'd like to merge all of the zinit-package-* repos into one single mono-repo.
Here's why:

  • the package repos only host a single package.json file
  • unlike plugins, packages do not get (git) cloned when installing them
  • it would increase zinit packages discoverability to only have to look for packages in a single repo
  • development and especially refactoring will be easier in the future. No need to update 10+ repos anymore if anything changes in the package.json format for example. (Example: zdharma-continuum/zinit-packages@630c49c)
  • the README of https://github.com/zdharma-continuum/zinit-packages would be the perfect place to put documentation about how to create a package. Currently, it is pretty much split across all the repos.

Per repo TODO:

zinit TODO:

  • Edit the URL that zinit uses to fetch package.json
  • Add depreciation notice in README.md and doc/CHANGELOG.md

Migration status:

Question: How to migrate from zdharma/zinit?

I used zinit before it was deleted, and I wanted to migrate to the new repository.
In ~/.zinit/bin, I ran:

git remote set-url origin https://github.com/zdharma-continuum/zinit.git

It seems to have worked; zinit self-update pulls from the new URL.
Screen Shot 2021-11-08 at 5 57 40 PM

Is this the recommended way of migrating? Perhaps some documentation could be added to the README to help other users.

📦 ziextract should rename .bzip2 files before attempting to extract

While working on zdharma-continuum/zinit-packages#2 I noticed that ziextract does detect bzip2 files correctly but ultimately fails to extract them when their suffix does not match bz2|bzip2.

This is actually a bunzip2 issue, it refuses to operate on files whose extension don't match.

bunzip2: zinit-package-apr: unknown suffix - ignored

This is easily fixable by renaming the file just before attempting the extraction. The same is already done for zx packages.

Refs:

Rewrite the installer

This is a follow up to #43

Installer wishlist:

  • Functions, everywhere!
  • No more color escapes sequences in the echo calls (but vars)
  • Optionally: Ask to install zsh-bin if no zsh installed (or zsh version < 5.5)
  • #45 ?

Wrong handling of ZDOTDIR in install script

Describe the bug
If $ZDOTDIR is set and $ZSHRC is not, the zinit installation script (scripts/install.sh) fails to update .zshrc with an error like:

sh: 214: cannot create /home/username/.zsh: Is a directory

Zinit config
~/.zshenv

export ZDOTDIR=$HOME/.zsh

~/.zsh/.zshrc

# empty

then run

sh -c "$(curl -fsSL https://git.io/zinit-install)"

Expected behavior
Update $ZDOTDIR/.zshrc without error

Versions:

  • $ZSH_VERSION == 5.8
  • Operating system name and version (uname -a): macOS, Linux (it is not related to operating system)

🧹 Repo clean up

A few things need to be removed or altered IMHO:

🐞 bug: `__git_zsh_bash_func:9: command not found: __git_aliased_command` when calling `zicompinit`

Issue description

Any time I call zicompinit, git's completion gets polluted by errors.

% git com<TAB>
_git:.:42: no such file or directory:

% git commit<TAB>
% git commit __git_zsh_bash_func:9: command not found: __git_aliased_command
  git commit

git version 2.31.1

zinit config

# Zinit
# sh -c "$(curl -fsSL https://git.io/zinit-install)"
### Added by Zinit's installer
if [[ ! -f $HOME/.local/share/zinit/zinit.git/zinit.zsh ]]; then
    print -P "%F{33} %F{220}Installing %F{33}ZDHARMA-CONTINUUM%F{220} Initiative Plugin Manager (%F{33}zdharma-continuum/zinit%F{220})…%f"
    command mkdir -p "$HOME/.local/share/zinit" && command chmod g-rwX "$HOME/.local/share/zinit"
    command git clone https://github.com/zdharma-continuum/zinit "$HOME/.local/share/zinit/zinit.git" && \
        print -P "%F{33} %F{34}Installation successful.%f%b" || \
        print -P "%F{160} The clone has failed.%f%b"
fi

source "$HOME/.local/share/zinit/zinit.git/zinit.zsh"
autoload -Uz _zinit
(( ${+_comps} )) && _comps[zinit]=_zinit

# Load a few important annexes, without Turbo
# (this is currently required for annexes)
zinit light-mode for \
    zdharma-continuum/zinit-annex-as-monitor \
    zdharma-continuum/zinit-annex-bin-gem-node \
    zdharma-continuum/zinit-annex-patch-dl \
    zdharma-continuum/zinit-annex-rust

# Plugins
# https://github.com/zdharma-continuum/fast-syntax-highlighting#zinit
zinit wait lucid light-mode for \
    atinit"ZINIT[COMPINIT_OPTS]=-C; zicompinit; zicdreplay" \
        zdharma-continuum/fast-syntax-highlighting

zinit version or commit ID

19347ba

zsh version

5.8

:boom: `atclone`'s exit code shoud be propagated to the parent `zinit` call

zinit currently "silently" fails when the atclone script fails:

zinit id-as"atclone-fails" atclone'echo atclone; false' for zdharma-continuum/null && echo okay || echo failed

Downloading zdharma-continuum/null... (at label: atclone-fails...)

Cloning into '/data/plugins/atclone-fails'...
▸▹▹▹▹ ███████████ OBJ: 100, , REC: 100%
No files for compilation found.
atclone
okay

The snippet above should echo failed.

Automatic install failed on MacOS

Describe the bug
When I run Automatic Install, the "mktemp" command exits with illegal options.

Zinit config
No

Expected behavior
Automatic install success.

Screenshots (optional)
No

Versions:

  • $ZSH_VERSION == zsh 5.8 (x86_64-apple-darwin20.0)
  • Operating system name and version (uname -a): Darwin mintrabi.local 20.6.0 Darwin Kernel Version 20.6.0: Tue Oct 12 18:33:42 PDT 2021; root:xnu-7195.141.8~1/RELEASE_X86_64 x86_64

Additional context
#43

installation error

Hello Everything is fine?

You're probably migrating the repository project and it's giving several errors in the installation, I think it's because the url zinit-zsh has changed...

Add a catchall wiki entry to redirect to for all broken links that cannot be restored (issues...)

We should create a wiki entry named null that explains why a specific link is dead.

And lists a few hints about where to maybe find the missing info regardless:

  • google cache
  • wayback machine
  • etc

Also, it should link to "create new issue" ;)

Originally posted by @pschmitt in #47 (comment)

TODOs:

💡 Proposal: Move doc/install.sh to another dir

While working on #43 I couldn't help but notice that the installer script is stored under doc/.

IMHO the doc/ dir should only - as the name implies - store documentation and not arbitrary scripts.

I'd like to move it to installer/install.sh or scripts/install/install.sh.
This shouldn't have many implications besides that the curl install instructions need to be updated once (and if) this is done.

Related: #55

za-rust-atclone-handler:8

Screenshots
If applicable, add screenshots to help explain your problem.
image

Versions:

  • $ZSH_VERSION == zsh 5.0.2 (x86_64-redhat-linux-gnu)
  • Operating system name and version (uname -a): Centos 7

No matter if I install themes or plug-ins, it always prompts like this:

za-rust-atclone-handler:8: array parameter za_rust_ef created globally in function

Neither the theme nor the plugin works.

By the way, I don’t have root privileges.

🤔 Some ices get ignored when run non-interactively

Describe the bug
When running non-interactively, for eg with Ansible, some ices get ignored. This also happens when run with zsh -sli.
My suspicion is that there's something fishy going with zsh hooks (add-zsh-hook) in this scenario, since this is how the make ice is called.

This makes it impossible to install everything in one go.

Zinit config

# make does not get executed when running `@zinit-scheduler-burst` w/o a TTY attached
zinit light-mode as"program" make for @direnv/direnv

Refs:

🌍 Translate the polish comments

There are few comments in zinit's codebase that are in polish.

We need to:

  • Find them! (is there a regex for polish words? :D)
  • Translate them!

Examples:

zinit/zinit.zsh

Lines 255 to 257 in 5e3e668

# "Elementy fpath" – tj. te elementy, które leżą wewnątrz katalogu wtyczki.
# Nazwa wynika z tego, że są to wybrane elementy fpath → a więc po prostu
# "elementy".

💡 Proposal: Drop `doc/NEWS.md`

It's out of date and the CHANGELOG seems to be a better place for updating people about the progress.
Plus there's already the "wiki".
Unless someone really wants it, and is willing to keep it up to date (I won't!) I think we should get rid of it as well.

🏷️ Rename zinit annex repositories

This sounds scarier than it is, promised!

To improve discoverability I suggest that we rename the repositories from z-a-${annex_name} to zinit-annex-${annex_name}.
This shouldn't break anything (™) as GitHub redirects to the new repo name.

TODO:

  • Update the references to the various annexes in code
  • Update the references to the various annexes in the documentation

wrong packages url in .zinit-get-package

Describe the bug

I am not able to install packages using the pack"" ice — I assume this is because the .zinit-get-package function has the wrong URL prefix zinit-package-... hardcoded:

URL=https://raw.githubusercontent.com/zdharma-continuum/zinit-package-$2/main/package.json

while the packages live under zsh-package-..., e.g. https://github.com/zdharma-continuum/zsh-package-fzf

To Reproduce

I have the following in my .zshrc

zinit wait"1" lucid if'[[ -z "$commands[fzf]" ]]' pack"bgn-binary+keys" for fzf

I get the following output when I open a new shell:

.zinit-get-package:25: datei oder Verzeichnis nicht gefunden: /tmp/tmp.06wsNmEHUB                                       
Error: the package `fzf` couldn't be found.

Expected behavior

Correcting the URL in zinit-install.zsh, and deleting the compiled .zwc fix this issue, and the packages install as expected.

Versions:

  • $ZSH_VERSION == 5.7.1
  • Operating system name and version (uname -a): Linux pi4 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux

.zinit-get-package error

.zinit-get-package:25: no such file or directory: /var/folders/jv/mdqy177n7sxbpqvqr55_9pwh0000gn/T/tmp.b9qfOmzv
Error: the package `fzf` couldn't be found.
.zinit-get-package:25: no such file or directory: /var/folders/jv/mdqy177n7sxbpqvqr55_9pwh0000gn/T/tmp.Z2EfO0JG
Error: the package `fzy` couldn't be found.

I got the above error, could someone help me?

🏛 Proposal: RETAB EVERYTHING!

The more I work with zinit's core the more my eyes bleed.
Some lines are absurdly long.
A few examples:

  • builtin source "${ZINIT[BIN_DIR]}/zinit-side.zsh" || { builtin print -P "${ZINIT[col-error]}ERROR:%f%b Couldn't find ${ZINIT[col-obj]}zinit-side.zsh%f%b."; return 1; }
  • (( !OPTS[opt_-q,--quiet] )) && +zinit-message "Downloading {apo}\`{url}$sname{apo}\`{rst}${${ICE[svn]+" (with Subversion)"}:-" (with curl, wget, lftp)"}{…}"
  • files=( ${(@)${(@s: :)${extract##(\!-|-\!|\!|-)}}//(#b)(((#s)|([^\\])[\\]([\\][\\])#)|((#s)|([^\\])([\\][\\])#)) /${match[2]:+$match[3]$match[4] }${match[5]:+$match[6]${(l:${#match[7]}/2::\\:):-} }} )

I get that most people don't stick to 80 chars for their code but I'd at least appreciate if we re-tabbed the zsh scripts to use 2 space chars instead of 4.

TL;DR
I'm advocating for vim: ft=zsh et ts=2 sw=2 for zinit*.zsh

📚 Install manpages automatically

Following #12 it now makes sense to have zinit automatically detect manages in plugins and symlink them to ZPX/man/man[1-9].

This leads the creation of a new ice nomanpages to explicitly disable that behavior (analogue to nocompletions)

TODOs:

  • zinit detects manpages if there is a myplugin.1 file in the root of the repo
  • Alternative paths get searched as well such as man/myplugin.1 or doc/man1/myplugin.1
  • no manpage gets symlinked if nomanpage is used

💡 Proposal: Sever the link between our forked repos and their parents

Have to admit, the title is weird.

Anyway we, zdharma-continuum, host a whole bunch of forked repos. AFAIK these were all created after the "deletening" (yes, I'm trying to make this is thing).

Some if not all of these forks have received updates. I don't think we'll ever "upstream" those changes back by opening PRs towards the original repos.
So, to improve discoverability and make our repo stand out a bit more we should IMHO get in touch with GH support to ask them to remove this "fork" relationship.

List of forks: https://github.com/orgs/zdharma-continuum/repositories?q=&type=fork&language=&sort=

TODO:

MANPATH doesn't have ~/.zinit/polaris/man, also ~/.zinit/polaris/man doesn't exist

Describe the bug
ZPFX=~/.zinit/polaris
MANPATH doesn't have $ZPFX/man, also $ZPFX/man doesn't exist.

To Reproduce

# requires the zdharma-continuum/z-a-bin-gem-node annex
# i'm also using ryaminal/z-a-meta-plugins to bring in the annexes(including the one above), but I don't anticipate this being a problem.
zinit wait'0b' lucid for \
  id-as'github-cli' from"gh-r" sbin'usr/bin/gh' atclone'ln -sf $PWD/usr/share/man/man1/* $ZPFX/man/man1' atpull'%atclone' cli/cli \
  ;

Expected behavior
Used to be that a $ZPFX/man directory was created and added to the MANPATH directory, this is the expected behavior.

Additional context
Mostly I'm just curious if anyone is familiar with why this wouldn't work? Are others seeing this directory existing and an entry in MANPATH? I've tried to look through the code but nothing is indicating the problem.

🏛 Proposal: Replace the wiki with GH wiki

Maintaining a separate web page is a pita, for me at least.

Having to update https://zdharma-continuum.github.io/zinit/wiki/ along with the NEWS section in the README (or doc/NEWS.md - see #44) is not something that will go too well in the future I believe.
It will probably get out of sync at some point, especially without CI. It may very well already be.

I don't think it is healthy to spread the documentation for zinit, especially after all that drama.
GitHub's wiki should be more than sufficient for our needs.

What do you guys think?

sbin annex does not work with zsh 5.4.2

Describe the bug
A clear and concise description of what the bug is.

sbin did not create any shim in corresponding directory. But when I delete the package, zinit warns that

bin-gem-node annex: The fzf shim didn't exist in $ZPFX/bin (or isn't a regular file)

Zinit config
Steps to reproduce the behavior. Please include any relevant config section
that may help the maintainers reproduce the issue.

zinit light-mode for \
    zdharma-continuum/z-a-rust \
    zdharma-continuum/z-a-patch-dl \
    zdharma-continuum/z-a-as-monitor \
    zdharma-continuum/z-a-bin-gem-node

zinit wait lucid from"gh-r" as"null" for \
    sbin"fzf" @junegunn/fzf \
    sbin"**/fd" @sharkdp/fd \
    sbin"**/bat" @sharkdp/bat \
    sbin"**/exa" @ogham/exa

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots (optional)
If applicable, add screenshots to help explain your problem.

Versions:

  • $ZSH_VERSION == 5.4.2
  • Operating system name and version (uname -a): ubuntu 18.04

Additional context
Add any other context about the problem here.

💡 Proposal: Update the name of the "master" branch to main

As the title states. The default is king and main is the new master.

TODOs:

  • Update the zinit self-update subcommand so that is switches automagically to the new branch
  • Update the installation doc to fetch the install.sh from the main branch, instead of master

💡 Proposal: Remove the remaining zplugin stuff

Eyeing a future (and first) release of the post-psprint era I'd like to properly remove all remaining compatibility for zplugin.

The 4.0 milestone is a major one so I think it is fair to finally remove compatibility with zplugin.
People using this here repo are by default already using zinit. We never hosted zplugin.

Let's get rid of:

  • zplugin-autoload.zsh
  • zplugin-install.zsh
  • zplugin-side.zsh
  • zplugin.zsh

Any objections?

gh-r does not rename downloaded binaries in some cases

Describe the bug
Does not mv gh-r downloaded files anymore (it worked with zinit ~6 month before or so, when I last used it to install a new computer)

Zinit config

          from"gh-r" as"program" mv"git-absorb* -> git-absorb" \
          load tummychow/git-absorb \

Expected behavior

I have a git-absorb command in my path, but only git-absorb-linux-x86_64 shows up

Screenshots (optional)

Downloading tummychow/git-absorb…
(Requesting `git-absorb-linux-x86_64'…)
############################################################################################################################################################################################################ 100.0%
ziextract: Successfully extracted and assigned +x chmod to the file: `git-absorb-linux-x86_64'.

All my other such lines download tar.gz and similar files and they do rename stuff, if there is a need.

Also, if I use

          from"gh-r" as"program" mv"git-absorb-* -> git-absorb" \
          load tummychow/git-absorb \

(note the minus between 'git-absorb' and the star),

then it works:

Downloading tummychow/git-absorb…
(Requesting `git-absorb-linux-x86_64'…)
############################################################################################################################################################################################################ 100.0%
ziextract: Successfully extracted and assigned +x chmod to the file: `git-absorb-linux-x86_64'.
renamed 'git-absorb-linux-x86_64' -> 'git-absorb'

Versions:

  • $ZSH_VERSION == 5.8
  • Operating system name and version (uname -a): Linux ... 5.15.0-2-amd64 #1 SMP Debian 5.15.5-1 (2021-11-26) x86_64 GNU/Linux
  • zinit update ran before sending this bugreport

Additional context
Add any other context about the problem here.

Remove all unicode emojis / symbols from file names

Describe the bug
Zinit cannot compile annex since some of the handler files have unicode chars in their names which zcompile does not support.
I wonder if we can dance around this issue by making the compile ice dynamically rename files.

Zinit config

zinit light-mode compile'*handler' for \
     zdharma-continuum/zinit-annex-bin-gem-node

Error output

(anon):zcompile:2: can't open file: /home/pschmitt/.local/share/zinit/plugins/zdharma-continuum---zinit-annex-bin-gem-node/\M-b\M-^F\M-^Rza-bgn-atclone-handler                                         
(anon):zcompile:2: can't open file: /home/pschmitt/.local/share/zinit/plugins/zdharma-continuum---zinit-annex-bin-gem-node/\M-b\M-^F\M-^Rza-bgn-atdelete-handler                                        
(anon):zcompile:2: can't open file: /home/pschmitt/.local/share/zinit/plugins/zdharma-continuum---zinit-annex-bin-gem-node/\M-b\M-^F\M-^Rza-bgn-atload-handler                                          
(anon):zcompile:2: can't open file: /home/pschmitt/.local/share/zinit/plugins/zdharma-continuum---zinit-annex-bin-gem-node/\M-b\M-^F\M-^Rza-bgn-help-handler

gh-r isn't searching for Apple Silicon compatible binaries correctly.

On my new M1 MacBookPro...

The gh-r ice isn't correctly grabbing the right binary packages that are using platform strings like x86_64-apple-darwin (usually Rust apps in my experience). e.g. ripgrep, git-delta, fd, led, and bat.

It's usually finding the linux arm binaries instead.

Here are my environment variables from zsh installed via Home-brew which is version zsh 5.8 (arm-apple-darwin21.1.0):

CPUTYPE=arm64
MACHTYPE=arm
OSTYPE=darwin21.1.0

When using /bin/zsh which is zsh 5.8 (x86_64-apple-darwin21.0):

CPUTYPE=arm64
MACHTYPE=x86_64
OSTYPE=darwin21.0
# An example command to cause the issue(s) in question.
zinit wait lucid for \
  from'gh-r' \
  as'program' \
  mv'lsd* -> lsd' \
  pick'lsd/lsd' \
  @Peltoche/lsd

I suspect the way to deal with this is to detect that it is an M1 macOS system and do an arm check then an intel type.

I don't think moving the CPUTYPE up in .zinit-get-latest-gh-r-url-part would be enough. Plus MACHTYPE won't check for amd64 unless it is /bin/zsh. A native zsh won't have any indication that it has Rosetta 2 installed and can handle amd64 binaries.

Yes, I can do experiments for you. 😃

Update the default install dir

As of now the zinit installer defaults to installing stuff under $HOME/.zinit/bin - which is a bit weird (the bin part especially) and clutters the users $HOME.

A more sensible default would be $XDG_DATA_HOME/zinit (ie. $HOME/.local/share/zinit).

Related to #28

Tasks:

  • update zinit installer to install to XDG_DATA_HOME
  • update documentation
  • update the migration wiki page

zdharma/zinit repository does not exist

Describe the bug
zdharma/zinit repository does not exist when try to install zinit from doc/install.sh

To Reproduce

sh -c "$(curl -fsSL https://raw.githubusercontent.com/zdharma-continuum/zinit/master/doc/install.sh)"

Expected behavior
install zinit

Versions:
zsh 5.8 (x86_64-apple-darwin21.0)

💡Proposal: Migration script?

To enable an easy and painless migration for the deleted zdharma, zsh-packages, zsh-zinit and psprint repos we should consider investing the time into creating either:

  • a one of script that would edit all the remotes of any affected pługins
  • Update zinit self-update to do that perhaps?

The issues I see with either approach are the following:

  • ⚠️ we shouldn't touch the users config file(s). Depending on the setup this might be very tricky to do anyway. A plugin report should be enough.
  • is it even worth the effort? Assuming most of the user-base that's left has already done the migration manually.

Maybe we should provide a script to do this automagically.

Originally posted by @pschmitt in #28 (comment)

Add reproducible performance tests comparing zinit and other plugin managers

One of the main selling points of zinit is that it's fast. Freakishly fast. Let's provide a quantifiable look into how fast it is. The chart in the README is old + probably outdated.

This is probably best thrown in some container that you can run on your own machine? No need to spend CI cycles on this.

We should set up identical configs for Oh-My-Zsh, zplug, and zinit and track "time to usable shell".

`zinit pack'5.8' for zsh` is broken

Describe the bug

The command zinit pack'5.8' for zsh is broken, but I'm not quite sure why.

To Reproduce

zinit pack'5.8' for zsh

Expected behavior

Following command would build zsh 5.8:

zinit pack'5.8' for zsh

Support 'unar' instead of requiring various unpackers (e.g. xz)

Is your feature request related to a problem? Please describe.

I'm frustrated when something requires an unpacker, such as xz.

Describe the solution you'd like

Recognize and support unar for unpacking archives.

Bonus points for adding a Zinit pack/annex (not sure which would be applicable here).

Describe alternatives you've considered

You gotta help us, Doc. We've tried nothin' and we're all out of ideas.

Recent clone

Hi,

I was shocked when I find the repo not syncing anymore and found your fork.

I have a recent clone of zinit with all branches. If you are interested, I can push it somewhere or send you a bundle. Just reach out for me by mail. :-D

Document purpose of organization and/or repo

I would suggest that we document the purpose of the organization and/or just this repo.

The I WANT TO HELP readme is a good start though it is mainly a broad "this happened and I had to take emergency action".

The information I'd be interested is:

  • Can we expect bug fixes once things settle down?
  • Can we expect security fixes?
  • How about new features?
  • Or even evolve into new things?

For example, the whole flag'value' thing (instead of --flag=value, while technically cool, is very non-standard and hinders adoption. Even if the feature is kept, the docs should probably shift to the (also supported) long-opt format (--flag=value).

🤳 Update the screenshots in the README

Right now, we feature a bunch of outdated screenshot that were taken before the rebranding to zinit and the "deletening".
The zplugin days are long over!

Can someone please take some glamour shots? Thanks!

💡 Proposal: Move the C module to another repo

To me at least the module deserves to be hosted in its own repo, esp. since it is neither a strict dependency of zinit, nor does it require zinit to be installed. Unix philosophy and all.

It does not make sense to have it lay around here. Even the annexes us separate repos after all.

TODO:

  • Find a fitting name for the module (maybe not "zinit-module")
  • Create a new repo w/ code and relevant README (https://github.com/zdharma-continuum/zinit-module)
  • Update zinit module build so that it fetches the source from the other repo
  • Remove the module from zinit's repo (./zmodules)
  • README.md: Link to new repo
  • Update doc/CHANGELOG.md

Related: #36

🤖 Extend the documentation workflow

We need CI for the really boring stuff: zsdoc, manpage, PDF. Otherwise they will get out of sync. Should be fairly trivial to add.
In CI we can generate all of these and ship them to the repo.

It think these artifacts can be stored in the gh-pages branch. Keeping them as build artifacts is sadly not an option because of the max lifetime of these (90 days?). Let me know if there's a more appropriate place for these.

TODO:

  • Rename and extend the gh-pages workflow
  • Move the files living in the documentation branch (mkdocs) to the main one
  • On-push generation of the zsdoc
  • On-push generation of the PDF
  • Remove the *.adoc, zsdoc/ etc from the main branch
  • Update any link pointing to the aforementioned doc artifacts
  • Update instructions in doc/README.md

Refs:

Clean up the README

Here is my plan:

  • Move the out of date NEWS section to NEWS.md (or: CHANGELOG.md)
  • Rename the modules install section title to Module installation (people may click on that in the TOC expecting to find the zinit install instructions)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.