python-can: bump to 1.4.1
PATCH 1/1 python-can: bump to 1.4.1
Add hash file and change download location to PyPi.
--- package/python-can/python-can.hash | 3 +++ package/python-can/python-can.mk | 5 ++--- 2 files changed, 5 insertions(+), 3 deletions(-) create mode 100644 package/python-can/python-can.hash
package/python-can/python-can.hash new file +3 -0
@@ -0,0 +1,3 @@ +# md5 from https://pypi.python.org/pypi?:action=show_md5&digest=63e922ae913bb0db1dd54e9189810130, sha256 locally computed +md5 63e922ae913bb0db1dd54e9189810130 python-can-1.4.1.tar.gz +sha256 ab60195d112504fc4d38b74fb4a6874cd509066472b9d6d3516a8ce1485cec6f python-can-1.4.1.tar.gz
package/python-can/python-can.mk +2 -3
@@ -4,9 +4,8 @@ # ################################################################################ -PYTHON_CAN_VERSION = ae5b6cf -PYTHON_CAN_SITE = https://bitbucket.org/hardbyte/python-can/get -PYTHON_CAN_SOURCE = $(PYTHON_CAN_VERSION).tar.bz2 +PYTHON_CAN_VERSION = 1.4.1 +PYTHON_CAN_SITE = https://pypi.python.org/packages/source/p/python-can PYTHON_CAN_LICENSE = LGPLv3 PYTHON_CAN_LICENSE_FILES = LICENSE.txt PYTHON_CAN_SETUP_TYPE = setuptools
Signature · 1 line
2.1.4
PATCH 1/1 python-can: bump to 1.4.1
Yegor, All,
On 2016-01-01 23:18 +0100, Yegor Yefremov spake thusly:
Quoted 1 line
Add hash file and change download location to PyPi.
Why did you change the location?
I think we want to use upstream locations as much as possible, and only fallback to alternative locations when there is no upstream, or upstream is flaky.
Regards,
Yann E. MORIN.
Quoted 39 lines
Signed-off-by Yegor Yefremov <[email protected]>--- package/python-can/python-can.hash | 3 +++ package/python-can/python-can.mk | 5 ++--- 2 files changed, 5 insertions(+), 3 deletions(-) create mode 100644 package/python-can/python-can.hashpackage/python-can/python-can.hash new file +3
-0@@ -0,0 +1,3 @@ +# md5 from https://pypi.python.org/pypi?:action=show_md5&digest=63e922ae913bb0db1dd54e9189810130, sha256 locally computed +md5 63e922ae913bb0db1dd54e9189810130 python-can-1.4.1.tar.gz +sha256 ab60195d112504fc4d38b74fb4a6874cd509066472b9d6d3516a8ce1485cec6f python-can-1.4.1.tar.gzpackage/python-can/python-can.mk +2
-3@@ -4,9 +4,8 @@ # ################################################################################ -PYTHON_CAN_VERSION = ae5b6cf -PYTHON_CAN_SITE = https://bitbucket.org/hardbyte/python-can/get -PYTHON_CAN_SOURCE = $(PYTHON_CAN_VERSION).tar.bz2 +PYTHON_CAN_VERSION = 1.4.1 +PYTHON_CAN_SITE = https://pypi.python.org/packages/source/p/python-can PYTHON_CAN_LICENSE = LGPLv3 PYTHON_CAN_LICENSE_FILES = LICENSE.txt PYTHON_CAN_SETUP_TYPE = setuptoolsSignature · 6 lines
2.1.4 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 python-can: bump to 1.4.1
Yegor, All,
On 2016-01-01 23:28 +0100, Yann E. MORIN spake thusly:
Quoted 8 lines
On 2016-01-01 23:18 +0100, Yegor Yefremov spake thusly:
Quoted 1 line
Add hash file and change download location to PyPi.
Why did you change the location?
I think we want to use upstream locations as much as possible, and only fallback to alternative locations when there is no upstream, or upstream is flaky.
OK, I think I know why you wanted to download from PyPi: the current package we have will download an archive named ae5b6cf.tar.gz without the name of the package.
That's because Bitbucket provides snapshots as such.
Also, there is not 'tag' per-se in the repository; upstream only updates the version in the setup.py script.
I don't think it is bad to use a hash when there is no human-readable version tagged. But we are currently using the short hash, when we require the full hash.
So, I'd suggest we fix it by using the Hg download method:
PYTHON_CAN_VERSION = 4085cffd2519f0ce21779e26b5c43ce8c007e9aa PYHTON_CAN_SITE = https://bitbucket.org/hardbyte/python-can
PYHTON_CAN_SITE_METHOD = hg
Then we have tarballs properly named with the package name and the full hash.
Care to update and respin, please? Thanks!
Regards,
Yann E. MORIN.
Quoted 54 lines
Regards,
Yann E. MORIN.Quoted 39 lines
Signed-off-by Yegor Yefremov <[email protected]>--- package/python-can/python-can.hash | 3 +++ package/python-can/python-can.mk | 5 ++--- 2 files changed, 5 insertions(+), 3 deletions(-) create mode 100644 package/python-can/python-can.hashpackage/python-can/python-can.hash new file +3
-0@@ -0,0 +1,3 @@ +# md5 from https://pypi.python.org/pypi?:action=show_md5&digest=63e922ae913bb0db1dd54e9189810130, sha256 locally computed +md5 63e922ae913bb0db1dd54e9189810130 python-can-1.4.1.tar.gz +sha256 ab60195d112504fc4d38b74fb4a6874cd509066472b9d6d3516a8ce1485cec6f python-can-1.4.1.tar.gzpackage/python-can/python-can.mk +2
-3@@ -4,9 +4,8 @@ # ################################################################################ -PYTHON_CAN_VERSION = ae5b6cf -PYTHON_CAN_SITE = https://bitbucket.org/hardbyte/python-can/get -PYTHON_CAN_SOURCE = $(PYTHON_CAN_VERSION).tar.bz2 +PYTHON_CAN_VERSION = 1.4.1 +PYTHON_CAN_SITE = https://pypi.python.org/packages/source/p/python-can PYTHON_CAN_LICENSE = LGPLv3 PYTHON_CAN_LICENSE_FILES = LICENSE.txt PYTHON_CAN_SETUP_TYPE = setuptoolsSignature · 6 lines
2.1.4 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildrootSignature · 10 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 python-can: bump to 1.4.1
Quoted 27 lines · Yann E. MORIN
Yegor, All,
On 2016-01-01 23:28 +0100, Yann E. MORIN spake thusly:
Quoted 8 lines
On 2016-01-01 23:18 +0100, Yegor Yefremov spake thusly:
Quoted 1 line
Add hash file and change download location to PyPi.
Why did you change the location?
I think we want to use upstream locations as much as possible, and only fallback to alternative locations when there is no upstream, or upstream is flaky.
OK, I think I know why you wanted to download from PyPi: the current package we have will download an archive named ae5b6cf.tar.gz without the name of the package.
That's because Bitbucket provides snapshots as such.
Also, there is not 'tag' per-se in the repository; upstream only updates the version in the
setup.pyscript.I don't think it is bad to use a hash when there is no human-readable version tagged. But we are currently using the short hash, when we require the full hash.
So, I'd suggest we fix it by using the Hg download method:
Quoted 8 lines
PYTHON_CAN_VERSION=4085cffd2519f0ce21779e26b5c43ce8c007e9aaPYHTON_CAN_SITE= https://bitbucket.org/hardbyte/python-can
PYHTON_CAN_SITE_METHOD= hgThen we have tarballs properly named with the package name and the full hash.
Care to update and respin, please? Thanks!
I don't always change download location for Python packages, but when I do, I change it to PyPi :-)
First of all it is simpler with checksums: you have official MD5 and in addition you add sha256.
PyPi is a standard place to download official package releases. Many Python packages in BR have PyPi. It is also very easy to add a new package using PyPi based package as template. I'm even thinking about making a PyPi helper.
Upstream repo can be used, if there are important fixes and official released is not planned.
What do you think?
Quoted 65 lines
Regards,
Yann E. MORIN.Quoted 49 lines
Regards,
Yann E. MORIN.Quoted 35 lines
Signed-off-by Yegor Yefremov <[email protected]>--- package/python-can/python-can.hash | 3 +++ package/python-can/python-can.mk | 5 ++--- 2 files changed, 5 insertions(+), 3 deletions(-) create mode 100644 package/python-can/python-can.hashpackage/python-can/python-can.hash new file +3
-0@@ -0,0 +1,3 @@ +# md5 from https://pypi.python.org/pypi?:action=show_md5&digest=63e922ae913bb0db1dd54e9189810130, sha256 locally computed +md5 63e922ae913bb0db1dd54e9189810130 python-can-1.4.1.tar.gz +sha256 ab60195d112504fc4d38b74fb4a6874cd509066472b9d6d3516a8ce1485cec6f python-can-1.4.1.tar.gzpackage/python-can/python-can.mk +2
-4@@ -4,9 +4,8 @@ # ################################################################################ -PYTHON_CAN_VERSION = ae5b6cf -PYTHON_CAN_SITE = https://bitbucket.org/hardbyte/python-can/get -PYTHON_CAN_SOURCE = $(PYTHON_CAN_VERSION).tar.bz2 +PYTHON_CAN_VERSION = 1.4.1 +PYTHON_CAN_SITE = https://pypi.python.org/packages/source/p/python-can PYTHON_CAN_LICENSE = LGPLv3 PYTHON_CAN_LICENSE_FILES = LICENSE.txt PYTHON_CAN_SETUP_TYPE = setuptools --2.1.4
Quoted 4 lines
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot--
.-----------------.--------------------.------------------.--------------------.| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |Quoted 5 lines
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot--
.-----------------.--------------------.------------------.--------------------.| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |'------------------------------^-------^------------------^--------------------'
PATCH 1/1 python-can: bump to 1.4.1
Yegor, All,
On 2016-01-02 10:05 +0100, Yegor Yefremov spake thusly:
Quoted 46 lines · Yann E. MORIN
Quoted 25 lines
On 2016-01-01 23:28 +0100, Yann E. MORIN spake thusly:
Quoted 8 lines
On 2016-01-01 23:18 +0100, Yegor Yefremov spake thusly:
Quoted 1 line
Add hash file and change download location to PyPi.
Why did you change the location?
I think we want to use upstream locations as much as possible, and only fallback to alternative locations when there is no upstream, or upstream is flaky.
OK, I think I know why you wanted to download from PyPi: the current package we have will download an archive named ae5b6cf.tar.gz without the name of the package.
That's because Bitbucket provides snapshots as such.
Also, there is not 'tag' per-se in the repository; upstream only updates the version in the
setup.pyscript.I don't think it is bad to use a hash when there is no human-readable version tagged. But we are currently using the short hash, when we require the full hash.
So, I'd suggest we fix it by using the Hg download method:
Quoted 8 lines
PYTHON_CAN_VERSION=4085cffd2519f0ce21779e26b5c43ce8c007e9aaPYHTON_CAN_SITE= https://bitbucket.org/hardbyte/python-can
PYHTON_CAN_SITE_METHOD= hgThen we have tarballs properly named with the package name and the full hash.
Care to update and respin, please? Thanks!
I don't always change download location for Python packages, but when I do, I change it to PyPi :-)
First of all it is simpler with checksums: you have official MD5 and in addition you add sha256.
PyPi is a standard place to download official package releases. Many Python packages in BR have PyPi. It is also very easy to add a new package using PyPi based package as template. I'm even thinking about making a PyPi helper.
Quoted 4 lines
Upstream repo can be used, if there are important fixes and official released is not planned.
What do you think?
As discussed on IRC: yeah, you were not the one who changed all the other PyPi-related locations. ;-)
I was only referring to that very patch.
Still, I think we should use upstream locations, not some packaging location. For example, switching to PyPi for Python packages would be like switching to Debian for 'native' packages. We don't do that (except when upstream has disapeared, is acting...)
The argument about the hash is only patially valid: md5 is long dead now, and you still have to compute a sha256 anyway.
But as seen on IRC: let's see what others think.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 python-can: bump to 1.4.1
Quoted 2 lines · Yann E. MORIN
Yegor, All,
[snip]
Quoted 4 lines
Still, I think we should use upstream locations, not some packaging location. For example, switching to PyPi for Python packages would be like switching to Debian for 'native' packages. We don't do that (except when upstream has disapeared, is acting...)
This analogy is not quite correct. PyPi is a distribution channel, not a
downstream. Not that I can think of a better analogy though. But the important thing is: the PyPi location is under control of the upstream author, so it is equally upstream as the git repo. Brian Thorne (the python-can author) doesn't upload tarballs to the bitbucket location (you only get the automatic ones), but only to PyPi. So there really is something to be said for using PyPi as the download location.
Quoted 3 lines
The argument about the hash is only patially valid: md5 is long dead now, and you still have to compute a sha256 anyway.
Very true.
Basically I'm OK with either location.
Regards,
Arnout
Quoted 6 lines
But as seen on IRC: let's see what others think.
Regards,
Yann E. MORIN.
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 python-can: bump to 1.4.1
Yegor, Arnout, All
2016-01-02 22:04 GMT+01:00 Arnout Vandecappelle <[email protected]>:
Quoted 11 lines · Yann E. MORIN
Quoted 2 lines
Yegor, All,
[snip]
Quoted 4 lines
Still, I think we should use upstream locations, not some packaging location. For example, switching to PyPi for Python packages would be like switching to Debian for 'native' packages. We don't do that (except when upstream has disapeared, is acting...)
Quoted 7 lines
This analogy is not quite correct. PyPi is a distribution channel, not a
downstream. Not that I can think of a better analogy though. But the important thing is: the PyPi location is under control of the upstream author, so it is equally upstream as the git repo. Brian Thorne (the python-can author) doesn't upload tarballs to the bitbucket location (you only get the automatic ones), but only to PyPi. So there really is something to be said for using PyPi as the download location.
I'm following (and contributing to) python-can for more than a year now and this is the first time in my memory that a release was uploaded to PyPi, and this happened cause someone asked for that on a project issue.
IMHO, it will not happen in the future again if not prompted by someone.
Indeed, I originally submitted the package using bitbucket as a source location, cause it was the only available.
Sincerely, Angelo.
Quoted 31 lines
Quoted 4 lines
The argument about the hash is only patially valid: md5 is long dead now, and you still have to compute a sha256 anyway.
Very true.
Basically I'm OK with either location.
Regards,
ArnoutQuoted 6 lines
But as seen on IRC: let's see what others think.
Regards,
Yann E. MORIN.--
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 1 line
Profile: http://it.linkedin.com/in/compagnucciangelo
PATCH 1/1 python-can: bump to 1.4.1
Quoted 26 lines · Angelo Compagnucci
Yegor, Arnout, All
2016-01-02 22:04 GMT+01:00 Arnout Vandecappelle <[email protected]>:
Quoted 11 lines
Quoted 11 lines · Yann E. MORIN
Quoted 2 lines
Quoted 2 lines
Yegor, All,
[snip]
Quoted 4 lines
Quoted 4 lines
Still, I think we should use upstream locations, not some packaging location. For example, switching to PyPi for Python packages would be like switching to Debian for 'native' packages. We don't do that (except when upstream has disapeared, is acting...)
Quoted 7 lines
Quoted 7 lines
This analogy is not quite correct. PyPi is a distribution channel, not a
downstream. Not that I can think of a better analogy though. But the important thing is: the PyPi location is under control of the upstream author, so it is equally upstream as the git repo. Brian Thorne (the python-can author) doesn't upload tarballs to the bitbucket location (you only get the automatic ones), but only to PyPi. So there really is something to be said for using PyPi as the download location.I'm following (and contributing to) python-can for more than a year now and this is the first time in my memory that a release was uploaded to PyPi, and this happened cause someone asked for that on a project issue.
Quoted 4 lines
IMHO, it will not happen in the future again if not prompted by someone.
Indeed, I originally submitted the package using bitbucket as a source location, cause it was the only available.
In that case we should stick to bitbucket as the source. If the next bump is
still available on pypi we can still switch then.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 python-can: bump to 1.4.1
Arnout, All
Quoted 27 lines · Arnout Vandecappelle
Quoted 26 lines · Angelo Compagnucci
Yegor, Arnout, All
2016-01-02 22:04 GMT+01:00 Arnout Vandecappelle <[email protected]>:
Quoted 11 lines
Quoted 11 lines · Yann E. MORIN
Quoted 2 lines
Quoted 2 lines
Yegor, All,
[snip]
Quoted 4 lines
Quoted 4 lines
Still, I think we should use upstream locations, not some packaging location. For example, switching to PyPi for Python packages would be like switching to Debian for 'native' packages. We don't do that (except when upstream has disapeared, is acting...)
Quoted 7 lines
Quoted 7 lines
This analogy is not quite correct. PyPi is a distribution channel, not a
downstream. Not that I can think of a better analogy though. But the important thing is: the PyPi location is under control of the upstream author, so it is equally upstream as the git repo. Brian Thorne (the python-can author) doesn't upload tarballs to the bitbucket location (you only get the automatic ones), but only to PyPi. So there really is something to be said for using PyPi as the download location.I'm following (and contributing to) python-can for more than a year now and this is the first time in my memory that a release was uploaded to PyPi, and this happened cause someone asked for that on a project issue.
Quoted 7 lines
Quoted 4 lines
IMHO, it will not happen in the future again if not prompted by someone.
Indeed, I originally submitted the package using bitbucket as a source location, cause it was the only available.
In that case we should stick to bitbucket as the source. If the next bump is
still available on pypi we can still switch then.
I've emaled Brian Thorne (maintainer of python-can) about PyPi publishing.
First of all he's very glad to see python-can being included into BR.
Second he agrees, that publishing updates on PyPi is the right solution and is willing to do so in the future.
Yegor
PATCH 1/1 python-can: bump to 1.4.1
Arnout, All
Quoted 38 lines · Yegor Yefremov
Arnout, All
Quoted 27 lines · Arnout Vandecappelle
Quoted 26 lines · Angelo Compagnucci
Yegor, Arnout, All
2016-01-02 22:04 GMT+01:00 Arnout Vandecappelle <[email protected]>:
Quoted 11 lines
Quoted 11 lines · Yann E. MORIN
Quoted 2 lines
Quoted 2 lines
Yegor, All,
[snip]
Quoted 4 lines
Quoted 4 lines
Still, I think we should use upstream locations, not some packaging location. For example, switching to PyPi for Python packages would be like switching to Debian for 'native' packages. We don't do that (except when upstream has disapeared, is acting...)
Quoted 7 lines
Quoted 7 lines
This analogy is not quite correct. PyPi is a distribution channel, not a
downstream. Not that I can think of a better analogy though. But the important thing is: the PyPi location is under control of the upstream author, so it is equally upstream as the git repo. Brian Thorne (the python-can author) doesn't upload tarballs to the bitbucket location (you only get the automatic ones), but only to PyPi. So there really is something to be said for using PyPi as the download location.I'm following (and contributing to) python-can for more than a year now and this is the first time in my memory that a release was uploaded to PyPi, and this happened cause someone asked for that on a project issue.
Quoted 7 lines
Quoted 4 lines
IMHO, it will not happen in the future again if not prompted by someone.
Indeed, I originally submitted the package using bitbucket as a source location, cause it was the only available.
In that case we should stick to bitbucket as the source. If the next bump is
still available on pypi we can still switch then.
Quoted 6 lines
I've emaled Brian Thorne (maintainer of python-can) about PyPi publishing.
First of all he's very glad to see python-can being included into BR.
Second he agrees, that publishing updates on PyPi is the right solution and is willing to do so in the future.
The python-can maintainer has published another version on PyPi, so we can change download location.
Yegor
PATCH 1/1 python-can: bump to 1.4.1
In reply to Yann E. MORINYann, all,
Quoted 3 lines · Yann E. MORIN
I think we want to use upstream locations as much as possible, and only fallback to alternative locations when there is no upstream, or upstream is flaky.
For Python packages, I actually find it quite practical when PyPi is used. Indeed, instead of having dozens of weird upstream locations and release behavior, you have one consistent way of fetching Python modules. It also makes it easier when reviewing new packages, when looking at package bumps, since you know what to expect from PyPi.
So I wouldn't be as strict as you said in terms of not using PyPi.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 python-can: bump to 1.4.1
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Yann, all,
Quoted 3 lines · Yann E. MORIN
I think we want to use upstream locations as much as possible, and only fallback to alternative locations when there is no upstream, or upstream is flaky.
Quoted 7 lines
For Python packages, I actually find it quite practical when PyPi is used. Indeed, instead of having dozens of weird upstream locations and release behavior, you have one consistent way of fetching Python modules. It also makes it easier when reviewing new packages, when looking at package bumps, since you know what to expect from PyPi.
So I wouldn't be as strict as you said in terms of not using PyPi.
I agree. I also find it "nice" to use pypi if we can (E.G. if we are using a release).
Signature · 1 line
Bye, Peter Korsgaard