[Buildroot] [PATCH] python-can: bump to 1.4.1

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Yegor Yefremov]

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

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Yegor Yefremov]

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.  |
> '------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Arnout Vandecappelle]

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

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Angelo Compagnucci]

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

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Thomas Petazzoni]

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

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Peter Korsgaard]

>>>>> "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

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Arnout Vandecappelle]

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

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Yegor Yefremov]

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

[Buildroot] [PATCH] python-can: bump to 1.4.1

[Yegor Yefremov]

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