diff options
Diffstat (limited to 'python-p.spec')
| -rw-r--r-- | python-p.spec | 293 |
1 files changed, 293 insertions, 0 deletions
diff --git a/python-p.spec b/python-p.spec new file mode 100644 index 0000000..10f7ebc --- /dev/null +++ b/python-p.spec @@ -0,0 +1,293 @@ +%global _empty_manifest_terminate_build 0 +Name: python-p +Version: 1.4.0 +Release: 1 +Summary: Aliases any available project commands or scripts to `p <name>`. +License: MIT +URL: https://www.dropseed.dev/p +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/88/27/9d05057da694ff15d3d921eff3c0c46075b98881c4f86f33d86782a8d137/p-1.4.0.tar.gz +BuildArch: noarch + +Requires: python3-click +Requires: python3-click-didyoumean + +%description +## Why +### Context switching sucks +It can often take several minutes just to figure out how to *start* working on +something. +Every project is different, but damn near every project comes with a set of +development commands or scripts to run common actions. And if it doesn’t, then +it probably should. +Different languages, people, and tools accomplish this in different ways. Some +projects use the good ol’ `Makefile`, while others use `package.json` “scripts”, +bash scripts, `rake`, `fabric`, and so on and so on… +P was built to make it easier to jump between projects, +and to save some keystrokes in the meantime. +### Improving developer experience +Ideally, p will “just work”. +But if not, +it is often in your project’s best interest to design a developer experience that *would* work if someone were using p. +That is – script out some of the most commonly used actions for your project (`install`, `test`, `deploy`, etc.), +and put them in a uniform place where contributors can easily figure out how to use them. +Now even the people who don't use p at least have a shot at getting up and running on their own. +### The search for a universal experience +For a long time I've been in search of the perfect development task manager to use on every project. +But that proved to be difficult as the repos got smaller, +more self-contained, +and spread across languages and dependency systems. +Using a Makefile is the closest thing to what I'm looking for. +Most people have `make`. +But there's a lot of things I just can't stand about it +(it's just ugly, and I can't help but think that it feels like some kind of *hack*). +I've settled on the idea of using a "scripts" folder with one-off files for each task. +Usually just bash scripts, +but can easily be a small Python script or something else. +These work basically everywhere, +and it's not hard to tell someone to do `./scripts/test`. +But even the "scripts" pattern doesn't make sense *on every project*. +Some frameworks/projects already come with a solution, +like pre-existing `package.json` "scripts". +Do we really want to create make `scripts/test` that just runs `npm run test`? +Seems dumb. +"I guess we'll use npm scripts on this project..." +So, every project inevitably ends up being a little bit different. +But for those of us that have to constantly jump around between those projects, +p smooths out the rough edges in our day-to-day, +and enables us to make per-project decisions about the developer experience +(and reminds us to even be thinking about that in the first place). +### Bonus: git hooks +Git hooks can be a super useful, +but confusing process to use. +The [gist](https://www.atlassian.com/git/tutorials/git-hooks#local-hooks) is that they generally aren't shared or set up for each user of a project automatically. +There are some tools like [pre-commit](https://pre-commit.com/) or [husky](https://github.com/typicode/husky) that really go the extra mile in creating a system for git hooks, +but a lot of our projects don't really warrant that and, +again, +it felt strange to now have a project dependency in that process... +Do we install that thing per-project even if the project doesn't use that language otherwise? +If we install it on our machines outside the project, +is that now a requirement that can't be required? +Is it even possible to run the hook/linter/formatter without that tool? +Anyway, p embraces git's (implied) attitude about hooks: they're optional. +If a user has p, +then we'll take an extra step to install the git hook for them and put things in place. +It's a nice-to-have. +If you don't have p, then at least you can still run your linters/formatters manually if you want (i.e. `npm run pre-commit`). +And if you need to *require* that those checks are run, +no matter who (or what) commits to the project? +Then set them up in CI. +You don't need anything special to do this -- +just run your script/command as a step like a non-p user would. +It's not fancy, +and it works for us. +## Inspired by +- [Dropseed’s](https://github.com/dropseed) project-cli (private) +- [Flint Hills Design’s](https://github.com/flinthillsdesign) fhd-cli (private) +- [https://github.com/github/scripts-to-rule-them-all](https://github.com/github/scripts-to-rule-them-all) +- [https://github.com/bkeepers/strappydoo](https://github.com/bkeepers/strappydoo) +- having too many projects + +%package -n python3-p +Summary: Aliases any available project commands or scripts to `p <name>`. +Provides: python-p +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-p +## Why +### Context switching sucks +It can often take several minutes just to figure out how to *start* working on +something. +Every project is different, but damn near every project comes with a set of +development commands or scripts to run common actions. And if it doesn’t, then +it probably should. +Different languages, people, and tools accomplish this in different ways. Some +projects use the good ol’ `Makefile`, while others use `package.json` “scripts”, +bash scripts, `rake`, `fabric`, and so on and so on… +P was built to make it easier to jump between projects, +and to save some keystrokes in the meantime. +### Improving developer experience +Ideally, p will “just work”. +But if not, +it is often in your project’s best interest to design a developer experience that *would* work if someone were using p. +That is – script out some of the most commonly used actions for your project (`install`, `test`, `deploy`, etc.), +and put them in a uniform place where contributors can easily figure out how to use them. +Now even the people who don't use p at least have a shot at getting up and running on their own. +### The search for a universal experience +For a long time I've been in search of the perfect development task manager to use on every project. +But that proved to be difficult as the repos got smaller, +more self-contained, +and spread across languages and dependency systems. +Using a Makefile is the closest thing to what I'm looking for. +Most people have `make`. +But there's a lot of things I just can't stand about it +(it's just ugly, and I can't help but think that it feels like some kind of *hack*). +I've settled on the idea of using a "scripts" folder with one-off files for each task. +Usually just bash scripts, +but can easily be a small Python script or something else. +These work basically everywhere, +and it's not hard to tell someone to do `./scripts/test`. +But even the "scripts" pattern doesn't make sense *on every project*. +Some frameworks/projects already come with a solution, +like pre-existing `package.json` "scripts". +Do we really want to create make `scripts/test` that just runs `npm run test`? +Seems dumb. +"I guess we'll use npm scripts on this project..." +So, every project inevitably ends up being a little bit different. +But for those of us that have to constantly jump around between those projects, +p smooths out the rough edges in our day-to-day, +and enables us to make per-project decisions about the developer experience +(and reminds us to even be thinking about that in the first place). +### Bonus: git hooks +Git hooks can be a super useful, +but confusing process to use. +The [gist](https://www.atlassian.com/git/tutorials/git-hooks#local-hooks) is that they generally aren't shared or set up for each user of a project automatically. +There are some tools like [pre-commit](https://pre-commit.com/) or [husky](https://github.com/typicode/husky) that really go the extra mile in creating a system for git hooks, +but a lot of our projects don't really warrant that and, +again, +it felt strange to now have a project dependency in that process... +Do we install that thing per-project even if the project doesn't use that language otherwise? +If we install it on our machines outside the project, +is that now a requirement that can't be required? +Is it even possible to run the hook/linter/formatter without that tool? +Anyway, p embraces git's (implied) attitude about hooks: they're optional. +If a user has p, +then we'll take an extra step to install the git hook for them and put things in place. +It's a nice-to-have. +If you don't have p, then at least you can still run your linters/formatters manually if you want (i.e. `npm run pre-commit`). +And if you need to *require* that those checks are run, +no matter who (or what) commits to the project? +Then set them up in CI. +You don't need anything special to do this -- +just run your script/command as a step like a non-p user would. +It's not fancy, +and it works for us. +## Inspired by +- [Dropseed’s](https://github.com/dropseed) project-cli (private) +- [Flint Hills Design’s](https://github.com/flinthillsdesign) fhd-cli (private) +- [https://github.com/github/scripts-to-rule-them-all](https://github.com/github/scripts-to-rule-them-all) +- [https://github.com/bkeepers/strappydoo](https://github.com/bkeepers/strappydoo) +- having too many projects + +%package help +Summary: Development documents and examples for p +Provides: python3-p-doc +%description help +## Why +### Context switching sucks +It can often take several minutes just to figure out how to *start* working on +something. +Every project is different, but damn near every project comes with a set of +development commands or scripts to run common actions. And if it doesn’t, then +it probably should. +Different languages, people, and tools accomplish this in different ways. Some +projects use the good ol’ `Makefile`, while others use `package.json` “scripts”, +bash scripts, `rake`, `fabric`, and so on and so on… +P was built to make it easier to jump between projects, +and to save some keystrokes in the meantime. +### Improving developer experience +Ideally, p will “just work”. +But if not, +it is often in your project’s best interest to design a developer experience that *would* work if someone were using p. +That is – script out some of the most commonly used actions for your project (`install`, `test`, `deploy`, etc.), +and put them in a uniform place where contributors can easily figure out how to use them. +Now even the people who don't use p at least have a shot at getting up and running on their own. +### The search for a universal experience +For a long time I've been in search of the perfect development task manager to use on every project. +But that proved to be difficult as the repos got smaller, +more self-contained, +and spread across languages and dependency systems. +Using a Makefile is the closest thing to what I'm looking for. +Most people have `make`. +But there's a lot of things I just can't stand about it +(it's just ugly, and I can't help but think that it feels like some kind of *hack*). +I've settled on the idea of using a "scripts" folder with one-off files for each task. +Usually just bash scripts, +but can easily be a small Python script or something else. +These work basically everywhere, +and it's not hard to tell someone to do `./scripts/test`. +But even the "scripts" pattern doesn't make sense *on every project*. +Some frameworks/projects already come with a solution, +like pre-existing `package.json` "scripts". +Do we really want to create make `scripts/test` that just runs `npm run test`? +Seems dumb. +"I guess we'll use npm scripts on this project..." +So, every project inevitably ends up being a little bit different. +But for those of us that have to constantly jump around between those projects, +p smooths out the rough edges in our day-to-day, +and enables us to make per-project decisions about the developer experience +(and reminds us to even be thinking about that in the first place). +### Bonus: git hooks +Git hooks can be a super useful, +but confusing process to use. +The [gist](https://www.atlassian.com/git/tutorials/git-hooks#local-hooks) is that they generally aren't shared or set up for each user of a project automatically. +There are some tools like [pre-commit](https://pre-commit.com/) or [husky](https://github.com/typicode/husky) that really go the extra mile in creating a system for git hooks, +but a lot of our projects don't really warrant that and, +again, +it felt strange to now have a project dependency in that process... +Do we install that thing per-project even if the project doesn't use that language otherwise? +If we install it on our machines outside the project, +is that now a requirement that can't be required? +Is it even possible to run the hook/linter/formatter without that tool? +Anyway, p embraces git's (implied) attitude about hooks: they're optional. +If a user has p, +then we'll take an extra step to install the git hook for them and put things in place. +It's a nice-to-have. +If you don't have p, then at least you can still run your linters/formatters manually if you want (i.e. `npm run pre-commit`). +And if you need to *require* that those checks are run, +no matter who (or what) commits to the project? +Then set them up in CI. +You don't need anything special to do this -- +just run your script/command as a step like a non-p user would. +It's not fancy, +and it works for us. +## Inspired by +- [Dropseed’s](https://github.com/dropseed) project-cli (private) +- [Flint Hills Design’s](https://github.com/flinthillsdesign) fhd-cli (private) +- [https://github.com/github/scripts-to-rule-them-all](https://github.com/github/scripts-to-rule-them-all) +- [https://github.com/bkeepers/strappydoo](https://github.com/bkeepers/strappydoo) +- having too many projects + +%prep +%autosetup -n p-1.4.0 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-p -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Mon May 15 2023 Python_Bot <Python_Bot@openeuler.org> - 1.4.0-1 +- Package Spec generated |