automatic import of python-p

3 files changed, 295 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..fe5a937 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/p-1.4.0.tar.gz
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
diff --git a/sources b/sources
new file mode 100644
index 0000000..76f576c
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+1ea28bbedc982c6fb50ba73755463a43  p-1.4.0.tar.gz