Re: Upstream has split a package in two -> new Debian package?

[Christoph Mathys]

On 05.04.2016 03:51, Ben Finney wrote:

Christoph Mathys  writes:

Upstream has split some of the functionality of mercurial-keyring into
a separate python library and pip package (mercurial_extension_utils).


That seems to imply there will be separate releases and versions for
‘mercurial_extension_utils’. Is that correct?


Yes, this is the case.


If the source is managed and released separately, with distinct release
schedule and versions, yes there should be separate Debian packages for
that.


OK. Thanks for the clear and quick response!

Christoph

Re: Upstream has split a package in two -> new Debian package?

[Ben Finney]

Christoph Mathys  writes:

> I'm the package maintainer of mercurial-keyring, a keyring extension
> for mercurial.

Thank you for maintaining this in Debian.

> Upstream has split some of the functionality of mercurial-keyring into
> a separate python library and pip package (mercurial_extension_utils).

That seems to imply there will be separate releases and versions for
‘mercurial_extension_utils’. Is that correct?

> Do I need to create and upload a new package for this library? Or is
> there another way?

If the source is managed and released separately, with distinct release
schedule and versions, yes there should be separate Debian packages for
that.

-- 
 \ “If nature has made any one thing less susceptible than all |
  `\others of exclusive property, it is the action of the thinking |
_o__)  power called an idea” —Thomas Jefferson, 1813-08-13 |
Ben Finney

Bug#820029: RFS: grip/4.1.0-1 [ITP]

[Tiago Ilieve]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-python@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "grip"

* Package name: grip
  Version : 4.1.0-1
  Upstream Author : Joe Esposito 
* URL : https://github.com/joeyespo/grip
* License : MIT
  Section : utils

It builds those binary packages:

grip  - Preview GitHub Markdown files like Readme locally

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/grip

Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/g/grip/grip_4.1.0-1.dsc

-

This package depends on "python-path-and-address" (RFS #819773[1]), which is
not on the archive yet. It would be awesome if the sponsor could help me with
both RFS bugs.

Tests are commented out in "debian/rules" because they depend on a newer
version of "python-responses". I've filled a bug (#820020[2]) which is now
pending (thanks Ondrej Novy!). This can be fixed as soon as the updated package
hits unstable.

Decisions made about packaging layout (Python application vs. Python library)
have been clarified on the "debian-python" mailing list[3].

I also would like to thanks Gustavo Panizzo, who gave me permission[4] to take
over his ITP.

Regards,
Tiago.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819773
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820020
[3]: https://lists.debian.org/debian-python/2016/04/msg00017.html
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611#17

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#820019: RFP: python-sframe -- scalable tabular (SFrame, SArray) and graph (SGraph) data-structures built for out-of-core data analysis.

[Rogério Brito]

Package: wnpp
Severity: wishlist

* Package name: python-sframe
  Version : 1.8.4
  Upstream Author : Dato, Inc.
* URL : https://github.com/dato-code/SFrame
* License : BSD
  Programming Lang: C++, Python
  Description : scalable tabular (SFrame, SArray) and graph (SGraph) 
data-structures built for out-of-core data analysis.

The SFrame package provides the complete implementation of:

* SFrame
* SArray
* SGraph
* The C++ SDK surface area (gl_sframe, gl_sarray, gl_sgraph)

The SFrame contains the open source components GraphLab Create from Dato.

For more details on GraphLab Create (including documentation and tutorials)
see http://dato.com.

Some of the key features of this package are.

* A scalable column compressed disk-backed dataframe optimized for machine
  learning and data science needs.
* Designed for both tabular (SFrame, SArray) as well as graph data (SGraph)
* Support for strictly typed columns (int, float, str, datetime), weakly
  typed columns (schema free lists, dictionaries) as well as specialized types
  such as Image.
* Uniform support for missing data.
* Query optimization and Lazy evaluation.
* A C++ API (gl_sarray, gl_sframe, gl_sgraph) with direct native access via
  the C++ SDK.
* A Python API (SArray, SFrame, SGraph) with an indirect access via an
  interprocess layer.



Since I am interested in this package, I am willing to help co-maintain it
(as soon as I orphan some packages of mine), especially if some other more
experienced module packager is willing to guide me through some of the
process of having a hybrid module like this one.

Also, since this package is very similar in spirit to Pandas, I'm including
the pandas mantainers as CC, in case they are interested here.


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Re: Packaging Grip

[Tiago Ilieve]

Hi,

The Style Guide for Packaging Python Libraries[1] states that in cases
like this, one should package the library for both Python 2 and 3,
creating a third package that contains the executable. As this package
is indeed intended to be used as a CLI application (as its description
says), I've followed the examples found in packages like python-django
and tox and:

- Didn't used the application layout which stores files in
"/usr/share/", as it has modules that needs to be imported later;
- Removed the entry point script that is automatically created;
- Added a custom and simple script[2] that imports and calls Grip's
main function;
- Ended up with a single package called "grip".

As I said, I didn't invented this and followed the practices that are
being used by bigger Python packages. I'm entirely open about
discussing those decisions with my future sponsor in the RFS that I'll
be filling later today.

Regards,
Tiago.

[1]: 
https://wiki.debian.org/Python/LibraryStyleGuide#Executables_and_library_packages
[2]: https://github.com/myhro/deb-grip/blob/0fc1143/debian/bin/grip

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Upstream has split a package in two -> new Debian package?

[Christoph Mathys]

Hi!

I'm the package maintainer of mercurial-keyring, a keyring extension for 
mercurial. Upstream has split some of the functionality of 
mercurial-keyring into a separate python library and pip package 
(mercurial_extension_utils). Do I need to create and upload a new 
package for this library? Or is there another way?


I doubt that this library will get a second user, but you never know...

For reference:
https://pypi.python.org/pypi/mercurial_extension_utils
https://pypi.python.org/pypi/mercurial_keyring

Thanks.
Christoph

Bug#820001: ITP: asynctest -- unittest extension to test code using asyncio

[Ezequiel Alfíe]

Package: wnpp
Version: N/A; reported 2016-04-04
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org

   Package name: asynctest
Version: 0.6.0
Upstream Author: Martin Richard 
URL: https://github.com/Martiusweb/asynctest
License: Apache 2
Description: unittest extension to test code using asyncio
 The package asynctest is built on top of the standard unittest module
and cuts down
 boilerplate code when testing libraries for asyncio.

-- 
Ezequiel Alfie

Re: dropping top patch with git-dpm

[Dmitry Shachnev]

Hi Brian,

On Mon, Apr 04, 2016 at 04:35:52PM +1000, Brian May wrote:
> Seems this isn't as easy as I hoped.
>
> brian@prune:~/tree/debian/python-modules/django-guardian$ git-dpm 
> checkout-patched
> grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
> grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
> Updating outdated 'patched'...
> Switched to branch 'patched'
> You are now in branch 'patched'
> brian@prune:~/tree/debian/python-modules/django-guardian$ git reset --hard 
> HEAD\^
> HEAD is now at 2e72565 Remove nonlocal image for Travis-ci.
> brian@prune:~/tree/debian/python-modules/django-guardian$ git-dpm 
> update-patches
> grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
> grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
> git-dpm: Calling merge-patched-into-debian first...
> git-dpm: ERROR: cowardly refusing to update patched to already merged 
> version!. Use --allow-revert to override!

This message suggests you to use --allow-revert — I believe it's what you need.

From the manpage:

  --allow-revert
  Usually reverting to an old state of the patched branch is not allowed, to
  avoid mistakes (like having only pulled the Debian branch and forgot to run
  checkout-patched). This option changes that so you can for example drop the
  last patch in your stack.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: dropping top patch with git-dpm

[Barry Warsaw]

On Apr 04, 2016, at 05:33 PM, Brian May wrote:

>Ok, so as I expected, integrating a new upstream release resolved this
>issue for me. git-dpm import-new-upstream left me in the patched
>directory, and I was able to drop the last patch and then run git-dpm
>update-patches.

When it works, it's magic. ;)

On the rare occasion where I've had to do it manually, I don't use reset.  I
checkout-patched then rebase -i upstream and drop the commit.  I don't know if
that's effectively the same thing as what you've done, and ISTR that it
doesn't always work, but I know that it sometimes does .

-Barry

Re: dropping top patch with git-dpm

[Brian May]

Brian May  writes:

> brian@prune:~/tree/debian/python-modules/django-guardian$ git-dpm 
> update-patches
> grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
> grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
> git-dpm: Calling merge-patched-into-debian first...
> git-dpm: ERROR: cowardly refusing to update patched to already merged 
> version!. Use --allow-revert to override!

Ok, so as I expected, integrating a new upstream release resolved this
issue for me. git-dpm import-new-upstream left me in the patched
directory, and I was able to drop the last patch and then run git-dpm
update-patches.

Something to watch out for however.
-- 
Brian May