* [Buildroot] [PATCH] python-can: bump to 1.4.1 @ 2016-01-01 22:18 Yegor Yefremov 2016-01-01 22:28 ` Yann E. MORIN 0 siblings, 1 reply; 12+ messages in thread From: Yegor Yefremov @ 2016-01-01 22:18 UTC (permalink / raw) To: buildroot Add hash file and change download location to PyPi. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> --- 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 diff --git a/package/python-can/python-can.hash b/package/python-can/python-can.hash new file mode 100644 index 0000000..fc9fc2a --- /dev/null +++ b/package/python-can/python-can.hash @@ -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 diff --git a/package/python-can/python-can.mk b/package/python-can/python-can.mk index c7b06a5..9a9d9df 100644 --- a/package/python-can/python-can.mk +++ b/package/python-can/python-can.mk @@ -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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-01 22:18 [Buildroot] [PATCH] python-can: bump to 1.4.1 Yegor Yefremov @ 2016-01-01 22:28 ` Yann E. MORIN 2016-01-01 22:49 ` Yann E. MORIN 2016-01-02 22:31 ` Thomas Petazzoni 0 siblings, 2 replies; 12+ messages in thread From: Yann E. MORIN @ 2016-01-01 22:28 UTC (permalink / raw) To: buildroot Yegor, All, On 2016-01-01 23:18 +0100, Yegor Yefremov spake thusly: > 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. > Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> > --- > 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 > > diff --git a/package/python-can/python-can.hash b/package/python-can/python-can.hash > new file mode 100644 > index 0000000..fc9fc2a > --- /dev/null > +++ b/package/python-can/python-can.hash > @@ -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 > diff --git a/package/python-can/python-can.mk b/package/python-can/python-can.mk > index c7b06a5..9a9d9df 100644 > --- a/package/python-can/python-can.mk > +++ b/package/python-can/python-can.mk > @@ -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 > > _______________________________________________ > 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-01 22:28 ` Yann E. MORIN @ 2016-01-01 22:49 ` Yann E. MORIN 2016-01-02 9:05 ` Yegor Yefremov 2016-01-02 22:31 ` Thomas Petazzoni 1 sibling, 1 reply; 12+ messages in thread From: Yann E. MORIN @ 2016-01-01 22:49 UTC (permalink / raw) To: buildroot Yegor, All, On 2016-01-01 23:28 +0100, Yann E. MORIN spake thusly: > On 2016-01-01 23:18 +0100, Yegor Yefremov spake thusly: > > 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. > Regards, > Yann E. MORIN. > > > Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> > > --- > > 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 > > > > diff --git a/package/python-can/python-can.hash b/package/python-can/python-can.hash > > new file mode 100644 > > index 0000000..fc9fc2a > > --- /dev/null > > +++ b/package/python-can/python-can.hash > > @@ -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 > > diff --git a/package/python-can/python-can.mk b/package/python-can/python-can.mk > > index c7b06a5..9a9d9df 100644 > > --- a/package/python-can/python-can.mk > > +++ b/package/python-can/python-can.mk > > @@ -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 > > > > _______________________________________________ > > 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. | > '------------------------------^-------^------------------^--------------------' > _______________________________________________ > 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-01 22:49 ` Yann E. MORIN @ 2016-01-02 9:05 ` Yegor Yefremov 2016-01-02 11:15 ` Yann E. MORIN 0 siblings, 1 reply; 12+ messages in thread From: Yegor Yefremov @ 2016-01-02 9:05 UTC (permalink / raw) To: buildroot On Fri, Jan 1, 2016 at 11:49 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > Yegor, All, > > On 2016-01-01 23:28 +0100, Yann E. MORIN spake thusly: >> On 2016-01-01 23:18 +0100, Yegor Yefremov spake thusly: >> > 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! 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? > Regards, > Yann E. MORIN. > >> Regards, >> Yann E. MORIN. >> >> > Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> >> > --- >> > 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 >> > >> > diff --git a/package/python-can/python-can.hash b/package/python-can/python-can.hash >> > new file mode 100644 >> > index 0000000..fc9fc2a >> > --- /dev/null >> > +++ b/package/python-can/python-can.hash >> > @@ -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 >> > diff --git a/package/python-can/python-can.mk b/package/python-can/python-can.mk >> > index c7b06a5..9a9d9df 100644 >> > --- a/package/python-can/python-can.mk >> > +++ b/package/python-can/python-can.mk >> > @@ -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 >> > >> > _______________________________________________ >> > 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. | >> '------------------------------^-------^------------------^--------------------' >> _______________________________________________ >> 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. | > '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-02 9:05 ` Yegor Yefremov @ 2016-01-02 11:15 ` Yann E. MORIN 2016-01-02 21:04 ` Arnout Vandecappelle 0 siblings, 1 reply; 12+ messages in thread From: Yann E. MORIN @ 2016-01-02 11:15 UTC (permalink / raw) To: buildroot Yegor, All, On 2016-01-02 10:05 +0100, Yegor Yefremov spake thusly: > On Fri, Jan 1, 2016 at 11:49 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote: > > On 2016-01-01 23:28 +0100, Yann E. MORIN spake thusly: > >> On 2016-01-01 23:18 +0100, Yegor Yefremov spake thusly: > >> > 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! > > 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? 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. -- .-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-02 11:15 ` Yann E. MORIN @ 2016-01-02 21:04 ` Arnout Vandecappelle 2016-01-02 21:50 ` Angelo Compagnucci 0 siblings, 1 reply; 12+ messages in thread From: Arnout Vandecappelle @ 2016-01-02 21:04 UTC (permalink / raw) To: buildroot On 02-01-16 12:15, Yann E. MORIN wrote: > Yegor, All, > [snip] > 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. > > 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 > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-02 21:04 ` Arnout Vandecappelle @ 2016-01-02 21:50 ` Angelo Compagnucci 2016-01-03 22:24 ` Arnout Vandecappelle 0 siblings, 1 reply; 12+ messages in thread From: Angelo Compagnucci @ 2016-01-02 21:50 UTC (permalink / raw) To: buildroot Yegor, Arnout, All 2016-01-02 22:04 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>: > On 02-01-16 12:15, Yann E. MORIN wrote: >> Yegor, All, >> > > [snip] > >> 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. 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. > >> >> 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 > >> >> 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 -- Profile: http://it.linkedin.com/in/compagnucciangelo ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-02 21:50 ` Angelo Compagnucci @ 2016-01-03 22:24 ` Arnout Vandecappelle 2016-01-04 8:54 ` Yegor Yefremov 0 siblings, 1 reply; 12+ messages in thread From: Arnout Vandecappelle @ 2016-01-03 22:24 UTC (permalink / raw) To: buildroot On 02-01-16 22:50, Angelo Compagnucci wrote: > Yegor, Arnout, All > > 2016-01-02 22:04 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>: >> > On 02-01-16 12:15, Yann E. MORIN wrote: >>> >> Yegor, All, >>> >> >> > >> > [snip] >> > >>> >> 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. > 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. 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 -- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-03 22:24 ` Arnout Vandecappelle @ 2016-01-04 8:54 ` Yegor Yefremov 2016-01-13 14:26 ` Yegor Yefremov 0 siblings, 1 reply; 12+ messages in thread From: Yegor Yefremov @ 2016-01-04 8:54 UTC (permalink / raw) To: buildroot Arnout, All On Sun, Jan 3, 2016 at 11:24 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > On 02-01-16 22:50, Angelo Compagnucci wrote: >> Yegor, Arnout, All >> >> 2016-01-02 22:04 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>: >>> > On 02-01-16 12:15, Yann E. MORIN wrote: >>>> >> Yegor, All, >>>> >> >>> > >>> > [snip] >>> > >>>> >> 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. >> 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. > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-04 8:54 ` Yegor Yefremov @ 2016-01-13 14:26 ` Yegor Yefremov 0 siblings, 0 replies; 12+ messages in thread From: Yegor Yefremov @ 2016-01-13 14:26 UTC (permalink / raw) To: buildroot Arnout, All On Mon, Jan 4, 2016 at 9:54 AM, Yegor Yefremov <yegorslists@googlemail.com> wrote: > Arnout, All > > On Sun, Jan 3, 2016 at 11:24 PM, Arnout Vandecappelle <arnout@mind.be> wrote: >> On 02-01-16 22:50, Angelo Compagnucci wrote: >>> Yegor, Arnout, All >>> >>> 2016-01-02 22:04 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>: >>>> > On 02-01-16 12:15, Yann E. MORIN wrote: >>>>> >> Yegor, All, >>>>> >> >>>> > >>>> > [snip] >>>> > >>>>> >> 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. >>> 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. >> >> 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. The python-can maintainer has published another version on PyPi, so we can change download location. Yegor ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-01 22:28 ` Yann E. MORIN 2016-01-01 22:49 ` Yann E. MORIN @ 2016-01-02 22:31 ` Thomas Petazzoni 2016-01-03 20:50 ` Peter Korsgaard 1 sibling, 1 reply; 12+ messages in thread From: Thomas Petazzoni @ 2016-01-02 22:31 UTC (permalink / raw) To: buildroot Yann, all, On Fri, 1 Jan 2016 23:28:35 +0100, Yann E. MORIN wrote: > 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 -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] [PATCH] python-can: bump to 1.4.1 2016-01-02 22:31 ` Thomas Petazzoni @ 2016-01-03 20:50 ` Peter Korsgaard 0 siblings, 0 replies; 12+ messages in thread From: Peter Korsgaard @ 2016-01-03 20:50 UTC (permalink / raw) To: buildroot >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Yann, all, > On Fri, 1 Jan 2016 23:28:35 +0100, Yann E. MORIN wrote: >> 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. I agree. I also find it "nice" to use pypi if we can (E.G. if we are using a release). -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-01-13 14:26 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-01-01 22:18 [Buildroot] [PATCH] python-can: bump to 1.4.1 Yegor Yefremov 2016-01-01 22:28 ` Yann E. MORIN 2016-01-01 22:49 ` Yann E. MORIN 2016-01-02 9:05 ` Yegor Yefremov 2016-01-02 11:15 ` Yann E. MORIN 2016-01-02 21:04 ` Arnout Vandecappelle 2016-01-02 21:50 ` Angelo Compagnucci 2016-01-03 22:24 ` Arnout Vandecappelle 2016-01-04 8:54 ` Yegor Yefremov 2016-01-13 14:26 ` Yegor Yefremov 2016-01-02 22:31 ` Thomas Petazzoni 2016-01-03 20:50 ` Peter Korsgaard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox