[Pandas-dev] Componentization

[Joris Van den Bossche]

2017-05-04 1:09 GMT+02:00 Wes McKinney <wesmckinn at gmail.com>:

>
> *TOPIC TWO:* We discussed this on the last dev meeting call, but I wanted
> to see what others think and if there's some action items. To help with
> more frequent pandas releases, particularly of subcomponents which are pure
> Python, I wonder if we could move toward a release model of "pandas" as a
> metapackage for a series of subcomponents which are packaged independently.
> As an example
>
> pandas depends on
>   pandas_display (Display for humans)
>   pandas_io
>   pandas_plotting
>   pandas_core
>
> and so forth. I think it would be better to go with a single codebase for
> this; I don't have a strong opinion about having separate release cycles,
> it's more to help establish cleaner boundaries about use of private and
> public APIs. Effectively the codebase is already organized like this, so
> I'm not sure concretely what we would want to do around this.
>
> Would your idea be to have those as separate python packages, but in a
single (github) repo?
If we want to go in this direction, I would first like to see some more
detailed practicalities, to be able to better evaluate if this would not
needlessly make the contributing cycle more complex.
Eg what would separate release cycles in practice mean? Would the
subpackages then need to support multiple versions of the base package (at
least master + latest stable, otherwise there is not really a benefit in a
separate release cycle)? That would also mean more testing builds? How
would it work with Travis with multiple packages in a single repo? (can it
run separate tests depending on the PR?)

Trying to establish cleaner boundaries between the private and public API's
is good goal, but in principle we could also try to do this in the current
directory layout (eg remove usage of private API's in pandas.plotting,
pandas.io, ..).

I am certainly not against a potential reorganisation on this front, but I
would like to see some more advantages in doing so (as I am not familiar
with such workflows from other project).

Regards,
Joris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20170513/e95bd6bc/attachment.html>