pash
pash copied to clipboard
binpash
RFC: FPM packaging
Package PaSh for system-level package managers using FPM
Update: 2022 March 10
I learned that macOS is not supported a bit late, so I'm stopping macOS work. I need acceptance criteria for this PR, so that I know what to do before this is ready to merge.
Update: 2022 March 7
Fedora working (without dictionary data) as of https://github.com/binpash/pash/pull/484/commits/ee36b6bccd2e07c6f4554ba0d69fc7f03ba5ec2e
Starting macOS. This will be the last supported platform on my end.
Update: 2022 March 4
Debian, Ubuntu, and Pop_OS! are working. Fedora has a problem with the the mv hack for Python site-packages and dist-packages. Arch lacks a dictionary for the intro example, but pa.sh runs.
This one is fun to review with tmux.
cd scripts/package
./iterate.sh ubuntu deb
./iterate.sh archlinux pacman
./iterate.sh fedora rpm
The system obsoletes many deployment scripts, but that doesn't really matter until packages are hosted somewhere.
Please review and let me know what you'd need to merge this as a feature.
Question: With C in mind, what target architectures are we talking about? I'm assuming noarch for the packages, but I don't know if I should.
Yes---my plan is to have something like pip install libdash put appropriate Python modules in the right place.
We would want to change setup.sh to use that new process, storing things wherever we're keeping the other vendored packages.
Yes---my plan is to have something like
pip install libdashput appropriate Python modules in the right place.We would want to change
setup.shto use that new process, storing things wherever we're keeping the other vendored packages.
Gotcha. I'm doing something different. Here, PaSh is a system level package, so pip is invoked as part of setup. You can see in the code how I tell FPM to prepare packages via /bin/python3 -m pip install. I can just as easily invoke your system in a post-install script, so we could collaborate there.
Last I heard anything about it, PaSh was vendoring dependencies in its own directory rather than installing on the system properly. My plan is to make libdash a conventional pip package, rather than a submodule of the pash repo. If PaSh is moving to a more conventional, system-package model, then great, it'll make everything easier---especially if setup is already using pip.
Last I heard anything about it, PaSh was vendoring dependencies in its own directory rather than installing on the system properly. My plan is to make libdash a conventional
pippackage, rather than a submodule of the pash repo. If PaSh is moving to a more conventional, system-package model, then great, it'll make everything easier---especially if setup is already using pip.
What you are making is fantastic, because we can simply list it in requirements.txt. Can we find a way to merge our powers? :)
And yes, you are correct, the Python packages are not properly set up. It all comes from difficulty organizing PaSh for use as a Python package itself. Moving to system packages solves a lot of problems you're having, and brings the focus towards distribution-specifics.
Nice! That means porting to my stuff should be easy, when it's ready.
My cleanup work is back on the original repo, at mgree/libdash on branch python-bindings. I don't have the setup.py/pyproject.toml written up yet.
@mgree How much overlap does your needed setup.py have with https://github.com/zyrolasting/pash/pull/1 ?
I would bet that I need a subset of what's in there, with probably only minor tweaks.
If you want to just ignore my stuff for now, and I'll steal the right parts/come up with a PR for pash, that works for me. Alternatively, I can ping you when I have a working setup.py and you can move pash to use the new module. Whatever's easy.
Sounds good. In the meantime, here's a demo video of the current state. +CC @nvasilakis
https://drive.google.com/file/d/1qQ_k6KiMxHcwtvbae4RCmyDi3nMWiecG/view?usp=sharing
If you can't see it, just note that my Pop_OS! seems to work, and FPM told me of an Arch-specific artifact appearing in my RPM build. Please start pulling down this branch and try your own format for review? I already know this won't work for all platforms, so I'd appreciate help bug hunting.
The installation instructions give me a general sense of intended support, but it would help if I knew what platforms and architectures you all want to see working first.
Looks like gcc10 was removed from the community repository for Arch, so distro-deps.sh is not correct for pacman.
https://archlinux.org/packages/community/x86_64/gcc10/
It still exists. Need to learn how Arch intends one to install packages not found in the AUR.
PR is ready for review. Bugs remain in some deployments, but I don't think it makes sense to block a merge over an undefined support profile. Please review the manual and system, and let me know what you need.
When running the deploy.sh for arch/ubuntu (haven't tested the others), I get:
/usr/lib/pash/compiler/pash_init_setup.sh: line 2: /root/.pash_init: No such file or directory
(pash runs correctly)
When running the deploy.sh for arch/ubuntu (haven't tested the others), I get:
/usr/lib/pash/compiler/pash_init_setup.sh: line 2: /root/.pash_init: No such file or directory(pash runs correctly)
Hi @zyrolasting, let @dkarnikis know when you fix this so that he can run another test — thanks!
When running the deploy.sh for arch/ubuntu (haven't tested the others), I get:
/usr/lib/pash/compiler/pash_init_setup.sh: line 2: /root/.pash_init: No such file or directory(pash runs correctly)Hi @zyrolasting, let @dkarnikis know when you fix this so that he can run another test — thanks!
So apparently, this is an issue cause by setup-pash.sh when running it with sudo (it generates the file in ~/ , in this case /root/).
We could manually copy the file from /root/ to the user directory or something like that.
Merge conflicts fixed, reopening for discussion and testing in light of new changes. Any comment I did not address here was addressed in an email, so please link me to any questions you'd like me to address here specifically. I'm removing pash-init.sh as a consequence of a discussion early in the PR's life.
Repeating the commands from the docs used to build and test the packages.
version=0.0.1
PATH="$PASH_TOP/scripts/package:$PATH"
deploy.sh archlinux $version pacman
deploy.sh debian $version deb
deploy.sh ubuntu $version deb
deploy.sh fedora $version rpm
Good news: No major change in behavior. Fedora and Arch launch PaSh successfully but without dictionary data (due to lack of wamerican-insane IIRC). Ubuntu and Debian run evaluation/intro/hello-world.sh without issue.
I still see the behavior @dkarnikis explains in https://github.com/binpash/pash/pull/484#issuecomment-1066167361 . I think this is out of scope for merging.
I manually approved the DCO sign-off, since A) I didn't know of the requirement until reading the details now, and B) I could certify I wrote the commits here with my manual approval to avoid a long rebase. If you'd rather I amend all of the commits, please let me know.