Re: Packaging multiple python modules in one Debian package

2016-07-19 Thread Fred Drake
On Tue, Jul 19, 2016 at 10:47 AM, Alexander Gerasiov  wrote:
> Every plugin is just a small parser class which is called from
> ofxstatement, parses input file and pass data back to main app. These
> plugins are developed independently by various people who publish them
> in separate repositories (mostly on github).

The high point I picked up here is that each plugin has it's own
lifecycle, controlled by independent developers.

> I decided to package ofxstatement as separate package, but put all
> plugins in one package oxfstatement-plugins.
>
> I'm not skilled in distributing python apps and packaging python
> apps into .deb, so I'd like to get some review and feedback from the
> community before upload to archive.

Grouping the plugins like this seems odd to me, because of the
independent lifecycles.  Perhaps something to consider is to create
separate debian packages for each (with names like
ofxstatement-plugin-abcdef), and maybe a convenience meta-package that
depends on some set of the plugin packages (ofxstatement-plugins).

I'm not sure whether the debian policies address this.  Hopefully
someone more knowledgable can comment on that.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein



Re: Test suite in github but missing from pypi tarballs

2016-04-21 Thread Fred Drake
On Apr 21, 2016 13:16, "Jeremy Stanley"  wrote:
> Agreed, as long as "closely" is interpreted in ways consistent with,
> say, tarballs for C-based projects. Consider `setup.py sdist`
> similar to `make dist` where the dist target of some projects may
> still run additional commands to generate metadata or other files
> not tracked in revision control prior to invoking tar/gzip.

That's exactly what I mean.

   -Fred


Re: Test suite in github but missing from pypi tarballs

2016-04-21 Thread Fred Drake
On Thu, Apr 21, 2016 at 11:48 AM, Ian Cordasco
 wrote:
> In the long history of both Python and its packaging this is
> absolutely true (all you need is an archive and a setup.py) but
> Python's packaging has evolved and improved for its users through
> setuptools, pip, and wheel (even though I'm sure there are many on
> this list who vehemently disagree). So tar files, for the *majority*
> of PyPI are there to help users with ancient, barely working, versions
> of pip, buildout, etc.

My reaction is really about the comment that source packages are in
PyPI "for pip". You definitely understand that it's broader than that,
but careful language is important to avoid confusing someone new,
leading to poor understanding across the community.

Some of us still see pip as a youngling upstart.  :-)

> There's also a lot of data that could be in a VCS tag that is
> orthogonal to what needs to be in a package for a user or
> redistributor. For example, few if any people are going to want a file
> that configures the (potentially closed-source) continuous integration
> service(s) that the project uses and it's inconsequential to a
> redistributor if a .gitignore is in the archive too.

Which is why I don't consider slavish use of "git archive" (or similar
from some other VCS) to be valuable.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein



Re: Amend Debian Python Proposal to Include More Python Metadata?

2016-01-22 Thread Fred Drake
On Fri, Jan 22, 2016 at 12:40 PM, Scott Kitterman  wrote:
> Currently --record includes the .pyc files which is both unneeded and bad.
> Before this gets added either in setuptools or by us, this needed to be fixed.

Why is this bad?  Isn't the point that the record file lists the files
installed by the installation process?  If the pyc files are installed
as part of the package, they should be listed.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein



Re: Amend Debian Python Proposal to Include More Python Metadata?

2016-01-22 Thread Fred Drake
On Fri, Jan 22, 2016 at 1:41 PM, Scott Kitterman  wrote:
> For Debian it's bad because we don't ship the .pyc files in the package they
> are managed locally by the installed python system.  They are also unnecessary
> because setuptools/pip/python is smart enough to relate .pyc files to their 
> .py
> files without them being listed.

The .pyc files aren't shipped in the .deb, or they aren't installed
when the .deb is installed?

If they're installed, I think they should be listed.  If not installed
when the package is installed, then they definitely shouldn't be
listed.

> Part of the goal here is to make sure that regardless of the installation
> method, there's a list of files that were installed.  Since Debian packages
> don't install the .pyc files, listing them is wrong.

I agree that listing them if they aren't installed is wrong.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein