Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-12-07 Thread Germano Massullo 
Il 20/11/2016 21:38, Nico Kadel-Garcia ha scritto:
>> I think it would be nice to make a discussion even for non Python
>> packages, so we can elaborate a sort of vademecum that a packager
>> could show to upstreams when there is a collaboration between them.
>>
>> Have a nice day
> Most upstream developers are happy to work with segregating
> components. A few... such as the awscli python package manager.
> use cfode with very bleeding edge and destabilizing dependencies.

Ok, concerning [1][2] (Python+ JavaScript), what would you suggest to
the upstream (Federico Capoano), in order to make the work easier for
both us and him?
Thank you

[1]: https://github.com/interop-dev/django-netjsongraph
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-26 Thread Nick Coghlan 
On 21 November 2016 at 21:49, Neal Gompa  wrote:
> On Mon, Nov 21, 2016 at 4:42 AM, Piotr Ozarowski  wrote:
>> In Debian we have https://wiki.debian.org/UpstreamGuide
>> I guess more official, cross-distro document that we all point upstream
>> authors to would be a nice idea as well.
>
> It would be a great idea if there were principles that all
> distributions could agree on and have a document codify that so that
> all distributions can reference it to upstream.

Donald Stufft laid out the Python upstream position in
https://caremad.io/posts/2013/07/setup-vs-requirement/

The gist is that for abstract dependencies (e.g. setup.py), we want
people to specify the cases that they know *don't* work:

- minimum versions
- maximum versions if there's a particular known breaking change, or
if a particular dependency is well-known for API breaks
- exclusions for known incompatibilities with particular versions

This is useful information for both end users and redistributors, as
it indicates the versions of dependencies that upstream will flat out
refuse to support.

By contrast, concrete dependencies (e.g. requirements.txt) are
intended for deployment rather than redistribution, and hence can (and
usually should) pin the exact combination of dependencies that was
tested.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-26 Thread Nick Coghlan 
On 21 November 2016 at 21:49, Neal Gompa  wrote:
> On Mon, Nov 21, 2016 at 4:42 AM, Piotr Ozarowski  wrote:
>> In Debian we have https://wiki.debian.org/UpstreamGuide
>> I guess more official, cross-distro document that we all point upstream
>> authors to would be a nice idea as well.
>
> It would be a great idea if there were principles that all
> distributions could agree on and have a document codify that so that
> all distributions can reference it to upstream.

Donald Stufft laid out the Python upstream position in
https://caremad.io/posts/2013/07/setup-vs-requirement/

The gist is that for abstract dependencies (e.g. setup.py), we want
people to specify the cases that they know *don't* work:

- minimum versions
- maximum versions if there's a particular known breaking change, or
if a particular dependency is well-known for API breaks
- exclusions for known incompatibilities with particular versions

This is useful information for both end users and redistributors, as
it indicates the versions of dependencies that upstream will flat out
refuse to support.

By contrast, concrete dependencies (e.g. requirements.txt) are
intended for deployment rather than redistribution, and hence can (and
usually should) pin the exact combination of dependencies that was
tested.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-25 Thread Germano Massullo 
Il 20/11/2016 21:38, Nico Kadel-Garcia ha scritto:
>> I think it would be nice to make a discussion even for non Python
>> packages, so we can elaborate a sort of vademecum that a packager
>> could show to upstreams when there is a collaboration between them.
>>
>> Have a nice day
> Most upstream developers are happy to work with segregating
> components. A few... such as the awscli python package manager.
> use cfode with very bleeding edge and destabilizing dependencies.

Ok, concerning [1][2] (Python+ JavaScript), what would you suggest to
the upstream (Federico Capoano), in order to make the work easier for
both us and him?
Thank you

[1]: https://github.com/interop-dev/django-netjsongraph
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-21 Thread Neal Gompa 
On Mon, Nov 21, 2016 at 4:42 AM, Piotr Ozarowski  wrote:
> Hi,
>
> [Germano Massullo, 2016-11-20]
>> We often deal with upstream developers that bundle libraries in their
>> code, so to make a package we have to debundle them, etc.
>> This time, an upstream dev. asked me what he could do to make easier
>> the work of packagers.
>> In this case the software is python-netjsongraph [1] that bundles
>> javascript-d3 library and that is being reviewd at [2]
>>
>> I think it would be nice to make a discussion even for non Python
>> packages, so we can elaborate a sort of vademecum that a packager
>> could show to upstreams when there is a collaboration between them.
>
> In Debian we have https://wiki.debian.org/UpstreamGuide
> I guess more official, cross-distro document that we all point upstream
> authors to would be a nice idea as well.

It would be a great idea if there were principles that all
distributions could agree on and have a document codify that so that
all distributions can reference it to upstream.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-21 Thread Neal Gompa 
On Mon, Nov 21, 2016 at 4:42 AM, Piotr Ozarowski  wrote:
> Hi,
>
> [Germano Massullo, 2016-11-20]
>> We often deal with upstream developers that bundle libraries in their
>> code, so to make a package we have to debundle them, etc.
>> This time, an upstream dev. asked me what he could do to make easier
>> the work of packagers.
>> In this case the software is python-netjsongraph [1] that bundles
>> javascript-d3 library and that is being reviewd at [2]
>>
>> I think it would be nice to make a discussion even for non Python
>> packages, so we can elaborate a sort of vademecum that a packager
>> could show to upstreams when there is a collaboration between them.
>
> In Debian we have https://wiki.debian.org/UpstreamGuide
> I guess more official, cross-distro document that we all point upstream
> authors to would be a nice idea as well.

It would be a great idea if there were principles that all
distributions could agree on and have a document codify that so that
all distributions can reference it to upstream.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-21 Thread Piotr Ozarowski 
Hi,

[Germano Massullo, 2016-11-20]
> We often deal with upstream developers that bundle libraries in their
> code, so to make a package we have to debundle them, etc.
> This time, an upstream dev. asked me what he could do to make easier
> the work of packagers.
> In this case the software is python-netjsongraph [1] that bundles
> javascript-d3 library and that is being reviewd at [2]
> 
> I think it would be nice to make a discussion even for non Python
> packages, so we can elaborate a sort of vademecum that a packager
> could show to upstreams when there is a collaboration between them.

In Debian we have https://wiki.debian.org/UpstreamGuide
I guess more official, cross-distro document that we all point upstream
authors to would be a nice idea as well.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-20 Thread Pete Travis 
On Nov 20, 2016 1:49 AM, "Germano Massullo" 
wrote:
>
> We often deal with upstream developers that bundle libraries in their
> code, so to make a package we have to debundle them, etc.
> This time, an upstream dev. asked me what he could do to make easier
> the work of packagers.
> In this case the software is python-netjsongraph [1] that bundles
> javascript-d3 library and that is being reviewd at [2]
>
> I think it would be nice to make a discussion even for non Python
> packages, so we can elaborate a sort of vademecum that a packager
> could show to upstreams when there is a collaboration between them.
>
> Have a nice day
>
>
> [1]: https://github.com/interop-dev/django-netjsongraph
> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213

For Python packages, my biggest complaint is when versioned dependencies
are explicitly declared without due diligence.  Rough example: Upstream
foobar developer gets foo-24.2 from pip, sets foo == 24.2 in their
requirements.  Fedora currently packages foo-21.8; foo usage doesn't change
for 18.0 < foo < 34.0 .  Add in 1-12 other dependencies, and I'm doing a
lot more manual work when updating foobar because upstream's declared
requirements simply are not useful in a distribution packaging context.

-- Pete
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-20 Thread Nico Kadel-Garcia 
On Sun, Nov 20, 2016 at 2:48 AM, Germano Massullo
 wrote:
> We often deal with upstream developers that bundle libraries in their
> code, so to make a package we have to debundle them, etc.
> This time, an upstream dev. asked me what he could do to make easier
> the work of packagers.
> In this case the software is python-netjsongraph [1] that bundles
> javascript-d3 library and that is being reviewd at [2]

I've just gone through this with a developer who believed that the
hand-built, hand-configured version of a library was better
incorporated in the git repo for the source code for the rest of the
package. It's mostly an education problem, to walk the developer
thorugh the cross-compatibility and compilation programs inherent in
embedding binaries into any source tree. And it's important to make
the separation of "this library gets built from *this* repo and
packaged as an RPM" distinct from bundling it for a different
package,especially an  RPM.

It's an old problem. Samba and Subversion, which I've been involved
with for years, both have this issue with their extensive reliance on
libraries that may be considerably more recent than system libraries.

> I think it would be nice to make a discussion even for non Python
> packages, so we can elaborate a sort of vademecum that a packager
> could show to upstreams when there is a collaboration between them.
>
> Have a nice day

Most upstream developers are happy to work with segregating
components. A few... such as the awscli python package manager.
use cfode with very bleeding edge and destabilizing dependencies.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-20 Thread Link Dupont 
On Sun, 2016-11-20 at 15:42 +, Zbigniew Jędrzejewski-Szmek wrote:
> I think it comes down to:
> - don't bundle,
> - if you have to bundle, provide an easy and unambiguous configure
> switch
>   to use the system version of the dependency,
> - never, never, patch stuff in-tree.

- Don't hard-code paths (respect things like CMake's GNUInstallDirs).
- Strongly consider using a configure/build system (autotools, cmake,
ninja, etc.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-20 Thread Zbigniew Jędrzejewski-Szmek 
On Sun, Nov 20, 2016 at 08:48:27AM +0100, Germano Massullo wrote:
> We often deal with upstream developers that bundle libraries in their
> code, so to make a package we have to debundle them, etc.
> This time, an upstream dev. asked me what he could do to make easier
> the work of packagers.
> In this case the software is python-netjsongraph [1] that bundles
> javascript-d3 library and that is being reviewd at [2]
> 
> I think it would be nice to make a discussion even for non Python
> packages, so we can elaborate a sort of vademecum that a packager
> could show to upstreams when there is a collaboration between them.

I think it comes down to:
- don't bundle,
- if you have to bundle, provide an easy and unambiguous configure switch
  to use the system version of the dependency,
- never, never, patch stuff in-tree.

Zbyszek
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

2016-11-20 Thread Zbigniew Jędrzejewski-Szmek 
On Sun, Nov 20, 2016 at 08:48:27AM +0100, Germano Massullo wrote:
> We often deal with upstream developers that bundle libraries in their
> code, so to make a package we have to debundle them, etc.
> This time, an upstream dev. asked me what he could do to make easier
> the work of packagers.
> In this case the software is python-netjsongraph [1] that bundles
> javascript-d3 library and that is being reviewd at [2]
> 
> I think it would be nice to make a discussion even for non Python
> packages, so we can elaborate a sort of vademecum that a packager
> could show to upstreams when there is a collaboration between them.

I think it comes down to:
- don't bundle,
- if you have to bundle, provide an easy and unambiguous configure switch
  to use the system version of the dependency,
- never, never, patch stuff in-tree.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org