Created attachment 211755 [details]
py-oci update to 2.10.5 version
py-oci update to 2.10.5 version
Thank you always!
BTW, is it possible to create a port for oci-cli?
Strangely, the distfile is just 1 byte short.
===> License APACHE20 UPL accepted by the user
===> py37-oci-2.10.5 depends on file: /usr/local/sbin/pkg - found
=> oci-2.10.5.tar.gz doesn't seem to exist in /portdistfiles/.
=> Attempting to fetch https://files.pythonhosted.org/packages/source/o/oci/oci-2.10.5.tar.gz
fetch: https://files.pythonhosted.org/packages/source/o/oci/oci-2.10.5.tar.gz: size mismatch: expected 196213, actual 1962132
mmmh, that is weird Koichiro, what commands did you run to get that error message?
I tried following ones, but it looks fine:
[ale@router ~]$ fetch https://files.pythonhosted.org/packages/source/o/oci/oci-2.10.5.tar.gz
oci-2.10.5.tar.gz 1916 kB 6880 kBps 00s
[ale@router ~]$ ls -l oci-2.10.5.tar.gz
-rw-r--r-- 1 ale ale 1962132 Feb 18 17:58 oci-2.10.5.tar.gz
[ale@router ~]$ sha256 oci-2.10.5.tar.gz
SHA256 (oci-2.10.5.tar.gz) = 05bde3f5390ceef7b256eed01a899ab38f0845a92c5348388408a7df3c641f27
with regards to the OCI cli question, yes, I am thinking about it, but I have a question: I noticed in setup.py file  that package depends on specific python libraries, for example oci-sdk version 2.10.5, configparser 3.5.0 or six 1.11.0.
What is the official FreeBSD policy with regards to such python packages? What about installing something in a virtualenv?
(In reply to Alessandro Sagratini from comment #3)
I tested it by poudriere but `make distclean stage` also reproduces the error.
Maybe it's ok to regenerate distinfo. I guess the tarball has been replaced silently.
A commit references this bug:
Date: Fri Feb 21 03:02:21 UTC 2020
New revision: 526603
deve/py-oci: Update to 2.10.5
- Support for the NoSQL Database service
- Support for filtering database versions by storage management type in the
- Support for specifying paid listing types within pricing models in the
- Support for primary and non-primary instance types in the Content and
Submitted by: Alessandro Sagratini <firstname.lastname@example.org> (maintainer)
(In reply to Alessandro Sagratini from comment #4)
Regarding oci-cli, I personally using virtualenv to install oci-cli. I suggest creating oci-cli port if it's easy but actually it sounds not easy, I stay on virtualenv.
I am a Ruby folk rather than Python but generally, requisite packages such as configparser 3.5.0 or six 1.11.0 should be created if oci-cli depends on them and doesn't exist in the ports tree. However, that will be too much hassle.
Thanks Koichiro, in the meantime, I kept in touch in freebsd-ports mailing list and got following response:
to recap, it seems to be too much of a work to keep the port up-to-date (in terms of testing), qa, etc): my understanding is to keep using oci-cli in a virtualenv, at the moment, as you correctly pointed out
since there is no further action on this bug, I am going to resolve it, let me know if you need anything else on this
(In reply to Alessandro Sagratini from comment #9)
Everything's done in this bug, thanks! Regarding oci-cli, stay on virtualenv.