automatic import of python-jill

1 files changed, 397 insertions, 0 deletions

diff --git a/python-jill.spec b/python-jill.spec
new file mode 100644
index 0000000..9a14cc1
--- /dev/null
+++ b/python-jill.spec
@@ -0,0 +1,397 @@
+%global _empty_manifest_terminate_build 0
+Name:		python-jill
+Version:	0.11.3
+Release:	1
+Summary:	JILL -- Julia Installer for Linux (MacOS, Windows and FreeBSD) -- Light
+License:	MIT
+URL:		https://github.com/johnnychen94/jill.py
+Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/b1/93/c5e134ae9c342b0168200b59a62e1861ce860c9e81041b544de675f0c287/jill-0.11.3.tar.gz
+BuildArch:	noarch
+
+Requires:	python3-wget
+Requires:	python3-requests
+Requires:	python3-fire
+Requires:	python3-semantic-version
+Requires:	python3-gnupg
+Requires:	python3-requests-futures
+Requires:	python3-jsonschema
+
+%description
+## Advanced: Example with cron
+If you're tired of seeing `(xx days old master)` in your nightly build version, then `jill` can
+make your nightly build always the latest version using `cron`:
+```bash
+# /etc/cron.d/jill
+PATH=/usr/local/bin:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin
+# install a fresh nightly build every day
+* 0 * * * root jill install latest --confirm --upstream Official
+```
+## Advanced: Registering a new public releases upstream
+If it's an public mirror and you want to share it worldwide to other users of JILL. You can add an
+entry to the [public registry](jill/config/sources.json), make a PR, then I will tag a new release
+for that.
+Please check [the `sources.json` format](sources_format.md) for more detailed information on the
+format.
+## Advanced: Specifying custom (private) downloading upstream
+To add new private upstream, you can create a file `~/.config/jill/sources.json` (fow Windows it is
+`~/AppData/Local/julias/sources.json`) and add your own upstream configuration just like the JILL
+[`sources.json`](jill/config/sources.json) does. Once this is done JILL will recognize this new
+upstream entry.
+Please check [the `sources.json` format](sources_format.md) for more detailed information on the
+format.
+## Advanced: make a Julia release mirror
+There are two ways to do so:
+* use `aws s3 sync`, this should be the easiest way to do so I highly recommend this.
+* **(Deprecated)** use `jill mirror` command with [mirror config example](mirror.example.json). I
+  didn't know about the `aws s3 sync` stuff when I implemented this.
+The Julia release mirror does not contain Julia package contents, to mirror all the Julia packages
+and artifacts (which requires >1.5Tb storage), you can use [StorageMirrorServer.jl].
+## Advanced: The Python API
+`jill.py` also provides a set of Python API:
+```python
+from jill.install import install_julia
+from jill.download import download_package
+# equivalent to `jill install --confirm`
+install_julia(confirm=True)
+# equivalent to `jill download`
+download_package()
+```
+You can read its docstring (e.g., `?install_julia`) for more information.
+## FAQs
+### Why you should use JILL?
+Distro package managers (e.g., `apt`, `pac`) is likely to provide a broken Julia with incorrect
+binary dependencies (e.g., LLVM ) versions. Hence it's recommended to download and extract the
+Julia binary provided in [Julia Downloads](https://julialang.org/downloads/). `jill.py` doesn't do
+anything magical, but just makes such operation even stupid.
+### Why I make the python fork of JILL?
+At first I found myself needing a simple tool to download and install Julia on my macbook and
+servers in our lab, I made my own shell scripts and I'd like to share it with others. Then I found
+the [jill.sh][JILL-sh] project, Abel knows a lot shell so I decide to contribute my macOS Julia
+installer to `jill.sh`.
+There are three main reasons for why I decided to start my Python fork:
+* I live in China. Downloading resources from GitHub and AWS s3 buckets is a painful experience.
+  Thus I want to support downloading from mirror servers. Adding mirror server support to jill.sh is
+  quite complicated and can easily become a maintenance nightmare.
+* I want to make a cross platform installer that everyone can use, not just Linux/macOS users. Shell
+  scripts doesn't allow this as far as I can tell. In contrast, Python allows this.
+* Most importantly, back to when I start this project, I knew very little shell, I knew nothing
+  about C/C++/Rust/Go and whatever you think a good solution is. I happen to knew a few Python.
+For some "obvious" reason, Julia People don't like Python and I understand it. (I also don't like
+Python after being advanced Julia user for more than 3 years) But to be honest, revisiting this
+project, I find using Python is one of the best-made decision during the entire project. Here is the
+reason: no matter how you enjoy Julia (or C++, Rust), Python is one of the best successful
+programming language for sever maintenance purpose. Users can easily found tons of "how-to"
+solutions about Python and it's easy to write, deploy, and ship Python codes to the world via PyPI.
+And again, I live in China so I want to rely on services that are easily accessible in China, PyPI
+is, GitHub and AWS S3 bucket aren't. A recent Julia installer project [juliaup] written in Rust
+solves the Python dependency problem very well, but the tradeoff is that `juliaup` needs its own
+distributing system (currently GitHub and S3 bucket) to make sure it can be reliably downloaded to
+user machine. And for this it just won't be as good as PyPI in the foreseeable future.
+### Is it safe to use `jill.py`?
+Yes, `jill.py` use GPG to check every tarballs after downloading. Also, `*.dmg`/`*.pkg` for macOS
+and `.exe` for Windows are already signed.
+### What's the difference between `jill.sh` and `jill.py`
+[`jill.sh`][JILL-sh] is a shell script that works quite well on Linux x86/x64 machines. `jill.py` is
+an enhanced python package that focus on Julia installation and version management, and brings a
+unified user experience on all platforms.
+### Why `julia` fails to start
+The symlink `julia` are stored in [JILL predefined symlinks
+dir](#About-installation-and-symlink-directories) thus you have to make sure this folder is in
+`PATH`. Search "how to add folder to PATH on xxx system" you will get a lot of solutions.
+### How do I use multiple patches releases (e.g., `1.6.1` and `1.6.2`)
+Generally, you should not care about patch version differences so `jill.py` make it explicitly that
+only one of 1.6.x can exist. If you insist to have multiple patch versions, you could use `jill
+install --install_dir <some_other_folder>` to install Julia in other folder, and then manually make
+a symlink back. As I just said, in most cases, common users should not care about this patch version
+difference and should just use the latest patch release.
+### How to only download contents without installation?
+Use `jill download [version] [--sys <system>] [--arch <arch>]`. Check `jill download --help` for
+more details.
+### Linux with musl libc
+For Julia (>= 1.5.0) in Linux with musl libc, you can just do `jill install` and it gives you the
+right Julia binary. To download the musl libc binary using `jill download`, you will need to pass
+`--sys musl` flag.
+### MacOS with Apple silicon (M1)
+Yes it's supported. Because macOS ARM version is still of tier-3 support, jill.py will by default
+install the x86_64 version. If you want to use the ARM version, you can install it via `jill install
+--preferred-arch arm64`.
+### CERTIFICATE_VERIFY_FAILED error
+If you're confident, try `jill install --bypass-ssl`.
+### Skip symbolic links generation
+If for some reason you prefer to download julia without generating symbolic links `jill install --skip-symlinks`
+<!-- URLS -->
+[Julia Repository]: https://github.com/JuliaLang/julia
+[JILL-sh]: https://github.com/abelsiqueira/jill
+[juliaup]: https://github.com/JuliaLang/juliaup
+[StorageMirrorServer.jl]: https://github.com/johnnychen94/StorageMirrorServer.jl
+
+%package -n python3-jill
+Summary:	JILL -- Julia Installer for Linux (MacOS, Windows and FreeBSD) -- Light
+Provides:	python-jill
+BuildRequires:	python3-devel
+BuildRequires:	python3-setuptools
+BuildRequires:	python3-pip
+%description -n python3-jill
+## Advanced: Example with cron
+If you're tired of seeing `(xx days old master)` in your nightly build version, then `jill` can
+make your nightly build always the latest version using `cron`:
+```bash
+# /etc/cron.d/jill
+PATH=/usr/local/bin:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin
+# install a fresh nightly build every day
+* 0 * * * root jill install latest --confirm --upstream Official
+```
+## Advanced: Registering a new public releases upstream
+If it's an public mirror and you want to share it worldwide to other users of JILL. You can add an
+entry to the [public registry](jill/config/sources.json), make a PR, then I will tag a new release
+for that.
+Please check [the `sources.json` format](sources_format.md) for more detailed information on the
+format.
+## Advanced: Specifying custom (private) downloading upstream
+To add new private upstream, you can create a file `~/.config/jill/sources.json` (fow Windows it is
+`~/AppData/Local/julias/sources.json`) and add your own upstream configuration just like the JILL
+[`sources.json`](jill/config/sources.json) does. Once this is done JILL will recognize this new
+upstream entry.
+Please check [the `sources.json` format](sources_format.md) for more detailed information on the
+format.
+## Advanced: make a Julia release mirror
+There are two ways to do so:
+* use `aws s3 sync`, this should be the easiest way to do so I highly recommend this.
+* **(Deprecated)** use `jill mirror` command with [mirror config example](mirror.example.json). I
+  didn't know about the `aws s3 sync` stuff when I implemented this.
+The Julia release mirror does not contain Julia package contents, to mirror all the Julia packages
+and artifacts (which requires >1.5Tb storage), you can use [StorageMirrorServer.jl].
+## Advanced: The Python API
+`jill.py` also provides a set of Python API:
+```python
+from jill.install import install_julia
+from jill.download import download_package
+# equivalent to `jill install --confirm`
+install_julia(confirm=True)
+# equivalent to `jill download`
+download_package()
+```
+You can read its docstring (e.g., `?install_julia`) for more information.
+## FAQs
+### Why you should use JILL?
+Distro package managers (e.g., `apt`, `pac`) is likely to provide a broken Julia with incorrect
+binary dependencies (e.g., LLVM ) versions. Hence it's recommended to download and extract the
+Julia binary provided in [Julia Downloads](https://julialang.org/downloads/). `jill.py` doesn't do
+anything magical, but just makes such operation even stupid.
+### Why I make the python fork of JILL?
+At first I found myself needing a simple tool to download and install Julia on my macbook and
+servers in our lab, I made my own shell scripts and I'd like to share it with others. Then I found
+the [jill.sh][JILL-sh] project, Abel knows a lot shell so I decide to contribute my macOS Julia
+installer to `jill.sh`.
+There are three main reasons for why I decided to start my Python fork:
+* I live in China. Downloading resources from GitHub and AWS s3 buckets is a painful experience.
+  Thus I want to support downloading from mirror servers. Adding mirror server support to jill.sh is
+  quite complicated and can easily become a maintenance nightmare.
+* I want to make a cross platform installer that everyone can use, not just Linux/macOS users. Shell
+  scripts doesn't allow this as far as I can tell. In contrast, Python allows this.
+* Most importantly, back to when I start this project, I knew very little shell, I knew nothing
+  about C/C++/Rust/Go and whatever you think a good solution is. I happen to knew a few Python.
+For some "obvious" reason, Julia People don't like Python and I understand it. (I also don't like
+Python after being advanced Julia user for more than 3 years) But to be honest, revisiting this
+project, I find using Python is one of the best-made decision during the entire project. Here is the
+reason: no matter how you enjoy Julia (or C++, Rust), Python is one of the best successful
+programming language for sever maintenance purpose. Users can easily found tons of "how-to"
+solutions about Python and it's easy to write, deploy, and ship Python codes to the world via PyPI.
+And again, I live in China so I want to rely on services that are easily accessible in China, PyPI
+is, GitHub and AWS S3 bucket aren't. A recent Julia installer project [juliaup] written in Rust
+solves the Python dependency problem very well, but the tradeoff is that `juliaup` needs its own
+distributing system (currently GitHub and S3 bucket) to make sure it can be reliably downloaded to
+user machine. And for this it just won't be as good as PyPI in the foreseeable future.
+### Is it safe to use `jill.py`?
+Yes, `jill.py` use GPG to check every tarballs after downloading. Also, `*.dmg`/`*.pkg` for macOS
+and `.exe` for Windows are already signed.
+### What's the difference between `jill.sh` and `jill.py`
+[`jill.sh`][JILL-sh] is a shell script that works quite well on Linux x86/x64 machines. `jill.py` is
+an enhanced python package that focus on Julia installation and version management, and brings a
+unified user experience on all platforms.
+### Why `julia` fails to start
+The symlink `julia` are stored in [JILL predefined symlinks
+dir](#About-installation-and-symlink-directories) thus you have to make sure this folder is in
+`PATH`. Search "how to add folder to PATH on xxx system" you will get a lot of solutions.
+### How do I use multiple patches releases (e.g., `1.6.1` and `1.6.2`)
+Generally, you should not care about patch version differences so `jill.py` make it explicitly that
+only one of 1.6.x can exist. If you insist to have multiple patch versions, you could use `jill
+install --install_dir <some_other_folder>` to install Julia in other folder, and then manually make
+a symlink back. As I just said, in most cases, common users should not care about this patch version
+difference and should just use the latest patch release.
+### How to only download contents without installation?
+Use `jill download [version] [--sys <system>] [--arch <arch>]`. Check `jill download --help` for
+more details.
+### Linux with musl libc
+For Julia (>= 1.5.0) in Linux with musl libc, you can just do `jill install` and it gives you the
+right Julia binary. To download the musl libc binary using `jill download`, you will need to pass
+`--sys musl` flag.
+### MacOS with Apple silicon (M1)
+Yes it's supported. Because macOS ARM version is still of tier-3 support, jill.py will by default
+install the x86_64 version. If you want to use the ARM version, you can install it via `jill install
+--preferred-arch arm64`.
+### CERTIFICATE_VERIFY_FAILED error
+If you're confident, try `jill install --bypass-ssl`.
+### Skip symbolic links generation
+If for some reason you prefer to download julia without generating symbolic links `jill install --skip-symlinks`
+<!-- URLS -->
+[Julia Repository]: https://github.com/JuliaLang/julia
+[JILL-sh]: https://github.com/abelsiqueira/jill
+[juliaup]: https://github.com/JuliaLang/juliaup
+[StorageMirrorServer.jl]: https://github.com/johnnychen94/StorageMirrorServer.jl
+
+%package help
+Summary:	Development documents and examples for jill
+Provides:	python3-jill-doc
+%description help
+## Advanced: Example with cron
+If you're tired of seeing `(xx days old master)` in your nightly build version, then `jill` can
+make your nightly build always the latest version using `cron`:
+```bash
+# /etc/cron.d/jill
+PATH=/usr/local/bin:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin
+# install a fresh nightly build every day
+* 0 * * * root jill install latest --confirm --upstream Official
+```
+## Advanced: Registering a new public releases upstream
+If it's an public mirror and you want to share it worldwide to other users of JILL. You can add an
+entry to the [public registry](jill/config/sources.json), make a PR, then I will tag a new release
+for that.
+Please check [the `sources.json` format](sources_format.md) for more detailed information on the
+format.
+## Advanced: Specifying custom (private) downloading upstream
+To add new private upstream, you can create a file `~/.config/jill/sources.json` (fow Windows it is
+`~/AppData/Local/julias/sources.json`) and add your own upstream configuration just like the JILL
+[`sources.json`](jill/config/sources.json) does. Once this is done JILL will recognize this new
+upstream entry.
+Please check [the `sources.json` format](sources_format.md) for more detailed information on the
+format.
+## Advanced: make a Julia release mirror
+There are two ways to do so:
+* use `aws s3 sync`, this should be the easiest way to do so I highly recommend this.
+* **(Deprecated)** use `jill mirror` command with [mirror config example](mirror.example.json). I
+  didn't know about the `aws s3 sync` stuff when I implemented this.
+The Julia release mirror does not contain Julia package contents, to mirror all the Julia packages
+and artifacts (which requires >1.5Tb storage), you can use [StorageMirrorServer.jl].
+## Advanced: The Python API
+`jill.py` also provides a set of Python API:
+```python
+from jill.install import install_julia
+from jill.download import download_package
+# equivalent to `jill install --confirm`
+install_julia(confirm=True)
+# equivalent to `jill download`
+download_package()
+```
+You can read its docstring (e.g., `?install_julia`) for more information.
+## FAQs
+### Why you should use JILL?
+Distro package managers (e.g., `apt`, `pac`) is likely to provide a broken Julia with incorrect
+binary dependencies (e.g., LLVM ) versions. Hence it's recommended to download and extract the
+Julia binary provided in [Julia Downloads](https://julialang.org/downloads/). `jill.py` doesn't do
+anything magical, but just makes such operation even stupid.
+### Why I make the python fork of JILL?
+At first I found myself needing a simple tool to download and install Julia on my macbook and
+servers in our lab, I made my own shell scripts and I'd like to share it with others. Then I found
+the [jill.sh][JILL-sh] project, Abel knows a lot shell so I decide to contribute my macOS Julia
+installer to `jill.sh`.
+There are three main reasons for why I decided to start my Python fork:
+* I live in China. Downloading resources from GitHub and AWS s3 buckets is a painful experience.
+  Thus I want to support downloading from mirror servers. Adding mirror server support to jill.sh is
+  quite complicated and can easily become a maintenance nightmare.
+* I want to make a cross platform installer that everyone can use, not just Linux/macOS users. Shell
+  scripts doesn't allow this as far as I can tell. In contrast, Python allows this.
+* Most importantly, back to when I start this project, I knew very little shell, I knew nothing
+  about C/C++/Rust/Go and whatever you think a good solution is. I happen to knew a few Python.
+For some "obvious" reason, Julia People don't like Python and I understand it. (I also don't like
+Python after being advanced Julia user for more than 3 years) But to be honest, revisiting this
+project, I find using Python is one of the best-made decision during the entire project. Here is the
+reason: no matter how you enjoy Julia (or C++, Rust), Python is one of the best successful
+programming language for sever maintenance purpose. Users can easily found tons of "how-to"
+solutions about Python and it's easy to write, deploy, and ship Python codes to the world via PyPI.
+And again, I live in China so I want to rely on services that are easily accessible in China, PyPI
+is, GitHub and AWS S3 bucket aren't. A recent Julia installer project [juliaup] written in Rust
+solves the Python dependency problem very well, but the tradeoff is that `juliaup` needs its own
+distributing system (currently GitHub and S3 bucket) to make sure it can be reliably downloaded to
+user machine. And for this it just won't be as good as PyPI in the foreseeable future.
+### Is it safe to use `jill.py`?
+Yes, `jill.py` use GPG to check every tarballs after downloading. Also, `*.dmg`/`*.pkg` for macOS
+and `.exe` for Windows are already signed.
+### What's the difference between `jill.sh` and `jill.py`
+[`jill.sh`][JILL-sh] is a shell script that works quite well on Linux x86/x64 machines. `jill.py` is
+an enhanced python package that focus on Julia installation and version management, and brings a
+unified user experience on all platforms.
+### Why `julia` fails to start
+The symlink `julia` are stored in [JILL predefined symlinks
+dir](#About-installation-and-symlink-directories) thus you have to make sure this folder is in
+`PATH`. Search "how to add folder to PATH on xxx system" you will get a lot of solutions.
+### How do I use multiple patches releases (e.g., `1.6.1` and `1.6.2`)
+Generally, you should not care about patch version differences so `jill.py` make it explicitly that
+only one of 1.6.x can exist. If you insist to have multiple patch versions, you could use `jill
+install --install_dir <some_other_folder>` to install Julia in other folder, and then manually make
+a symlink back. As I just said, in most cases, common users should not care about this patch version
+difference and should just use the latest patch release.
+### How to only download contents without installation?
+Use `jill download [version] [--sys <system>] [--arch <arch>]`. Check `jill download --help` for
+more details.
+### Linux with musl libc
+For Julia (>= 1.5.0) in Linux with musl libc, you can just do `jill install` and it gives you the
+right Julia binary. To download the musl libc binary using `jill download`, you will need to pass
+`--sys musl` flag.
+### MacOS with Apple silicon (M1)
+Yes it's supported. Because macOS ARM version is still of tier-3 support, jill.py will by default
+install the x86_64 version. If you want to use the ARM version, you can install it via `jill install
+--preferred-arch arm64`.
+### CERTIFICATE_VERIFY_FAILED error
+If you're confident, try `jill install --bypass-ssl`.
+### Skip symbolic links generation
+If for some reason you prefer to download julia without generating symbolic links `jill install --skip-symlinks`
+<!-- URLS -->
+[Julia Repository]: https://github.com/JuliaLang/julia
+[JILL-sh]: https://github.com/abelsiqueira/jill
+[juliaup]: https://github.com/JuliaLang/juliaup
+[StorageMirrorServer.jl]: https://github.com/johnnychen94/StorageMirrorServer.jl
+
+%prep
+%autosetup -n jill-0.11.3
+
+%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-jill -f filelist.lst
+%dir %{python3_sitelib}/*
+
+%files help -f doclist.lst
+%{_docdir}/*
+
+%changelog
+* Mon May 15 2023 Python_Bot <Python_Bot@openeuler.org> - 0.11.3-1
+- Package Spec generated