Distribution & Refactoring

[cordx56]

about distribution & refactoring

[cordx56]

Change dir structure:

├── build.rs
├── Cargo.lock
├── Cargo.toml
├── docs
│   ├── assets
│   │   ├── readme-screenshot-2.png
│   │   ├── readme-screenshot-3.png
│   │   ├── readme-screenshot.png
│   │   ├── rustowl-logo-dark.svg
│   │   ├── rustowl-logo.svg
│   │   ├── vs-code-cursor-on-unwrap.png
│   │   ├── vs-code-cursor-on-unwrap-visualized.png
│   │   └── vs-code-progress.png
│   ├── lsp-spec.md
│   └── usage.md
├── example
│   ├── all.rs
│   └── scope.rs
├── integrations
│   ├── emacs
│   │   └── rustowl.el
│   ├── neovim
│   │   ├── ftplugin
│   │   │   └── rust.lua
│   │   └── lua
│   │       └── rustowl
│   │           ├── config.lua
│   │           ├── highlight.lua
│   │           ├── init.lua
│   │           ├── lsp.lua
│   │           └── show-on-hover.lua
│   └── vscode
│       ├── esbuild.js
│       ├── eslint.config.mjs
│       ├── LICENSE
│       ├── package.json
│       ├── README.md
│       ├── rustowl-icon.png
│       ├── sample.rs
│       ├── src
│       │   ├── bootstrap.ts
│       │   ├── extension.ts
│       │   └── schemas.ts
│       ├── tsconfig.json
│       └── yarn.lock
├── LICENSE
├── README.md
├── rust-toolchain.toml
├── src
│   ├── bin
│   │   └── rustowl.rs
│   ├── cli.rs
│   ├── core
│   │   └── analyze.rs
│   ├── core.rs
│   ├── lib.rs
│   ├── lsp
│   │   ├── decoration.rs
│   │   └── progress.rs
│   ├── lsp.rs
│   ├── main.rs
│   ├── models.rs
│   ├── shells.rs
│   ├── toolchain_version.rs
│   └── utils.rs
└── version.sh

I will do this.

[cordx56]

@MuntasirSZN

the neovim folder with a Branch (named neovim) in the repo.

This approach requires users to add additional config. And Neovim plugin will become unable to managed by tag.

we should migrate the intellij and nix flake in the repo, for the future. We need maintainers afaik.

Nix flake is managed in nix-community, so maybe it is better.
for IntelliJ plugin, we have to ask @siketyan to become RustOwl maintainer since one of us (RustOwl maintainers) have to be able to maintain our code.

[MuntasirSZN]

No, it can be managed by tags. Lazy or others use gits tagging, not github release tags. Those git tags can be created in that branch via ci.

No additional config, just another line of lua:

branch = "neovim" -- in case of lazy.nvim

[siketyan]

I can't see why the IntelliJ plugin should be moved here (the original post has been deleted?)

[MuntasirSZN]

I can't see why the IntelliJ plugin should be moved here (the original post has been deleted?)

There is neovim, emacs, sublime (requested), vscode thats why. Though if you insist on keeping it there, then its up to you.

[siketyan]

I would be happy to transfer my repo, if you are interested and going to lead maintenance yourself. However, if you are going to invite to have me maintain the plugin, I would suggest to keep it third-party. It doesn't matter where the code is, but who maintains the code.

[MuntasirSZN]

I would be happy to transfer my repo, if you are interested and going to lead maintenance yourself. However, if you are going to invite to have me maintain the plugin, I would suggest to keep it third-party. It doesn't matter where the code is, but who maintains the code.

Ok.

[cordx56]

@MuntasirSZN

Those git tags can be created in that branch via ci.

But it is different from release's one, right? Then, I'm not prefer to do that.

[MuntasirSZN]

I think it is better to unify not squash but merge commit. I don't know when we feel squash as handy. However there is no sound grounds so I can turn on squash merge.

Merging only will add an unnecessary Merge Pull Request from commit, also if the author added multiple commits that does only one thing, but divided and fixed on multiple commits will add weird commits on repo.

[cordx56]

OK, I'm beginner in OSS dev, so I follow your advice.

[MuntasirSZN]

OK, I'm beginner in OSS dev, so I follow your advice.

No no. I am a beginner. Frankly speaking, I am just a 15 year old.

[cordx56]

Oh you are young! Good, you have a bright future.

I understand that merge commit is noisy, so we should try searching the bast way.

[MuntasirSZN]

Oh you are young! Good, you have a bright future.

I understand that merge commit is noisy, so we should try searching the bast way.

Thanks! It depends. If you are seeing weird commits that shouldn't be merged, like all commits do one thing and others just fixes things, we squash. It removes the weird merge commit in commit history. Also, if there is one commit, we still do the same, same reason. You can also do rebase and merge if it needs rebasing.

[MuntasirSZN]

My current targets:

1. Windows

• winget (Done)
• scoop
• chocolatey (choco)

2. Mac

• brew (homebrew) (rustowl 0.3.2 (new formula) Homebrew/homebrew-core#223535, failed, have to make a tap)
• macports

3. Linux (oh boyyy)

• apt (debian, we will reach them, not ubuntu, ubuntu will sync from there) (itp request made)
• AUR (after that pacman, the main) (Done)
• AUR git (builds from source, then installs) (Done)
• yum (rpm archives?)
• zypper

Below are not that important, will do later.

• apk (alpine)
• conda
• dnf
• pkg (termux)
• pkgin (netbsd)
• pkg_add (openbsd)
• portage
• xbps

[MuntasirSZN]

OK, I see. Building RustOwl requires these dependencies, as do rustc and clippy.

So now we need to maintain whats called a tap. Check MuntasirSZN/homebrew-programs , clone it, remove Formula/g dir And info dir, Create Formula/r dir, go to the my homebrew pr, copy that file, paste to Formula/r/rustowl.rb, and push the repo. Which will end up like cordx56/homebrew-programs, and done!

Now to install, just run brew install cordx56/programs/rustowl.

[cordx56]

@MuntasirSZN It is difficult for me to maintain the program that updates the package repository, and it seems that communities everywhere are reluctant to publish.
If possible, I would like to entrust you with managing these. Could you create and manage a workflow for these updates in your repository? If necessary, we can call that reusable workflow from our workflow.

[MuntasirSZN]

Its not possible @cordx56. Idk whats making you maintain the 'package repository'? You don't really need to. Just create the PAT, fork the repo, and thats it.

[cordx56]

Is there no need to maintenance forked repo?
I am very busy now and I cannot make even a little time for now.

[MuntasirSZN]

Is there no need to maintenance forked repo?
I am very busy now and I cannot make even a little time for now.

@cordx56 No.