[Sheets] Python Console Docker

Fri Jan 22 08:26:16 GMT 2016

On 22 January 2016 at 04:50, David Narvaez <david.narvaez at computer.org>
wrote:

> On Thu, Jan 21, 2016 at 3:59 AM, Jaroslaw Staniek <staniek at kde.org> wrote:
> > Short answer, not many commits for that, even dedicated maintainer
> probably
> > welcome, no special interest resulting in real coding, and especially,
> > organized design.
> >
> > Longer answer require showing more context.
> >
> > I can first mention atmosphere around Python and scripting in general
> closer
> > to the Kexi circles.
> >
> > But I believe since the intent is to have consistent scripting in the
> > future, it somehow helps to see some relation to Sheets, being in the
> same
> > class of apps.
> >
> > As some people may know I like Python for its purposes. KDE even started
> (in
> > Calligra) projects such as Kross to support more languages honestly. This
> > support was were means for not too deep bindings, not language-specific,
> > rather calling methods of objects without much regard to integration with
> > data types or language specifics.
> >
> > As a part of general 'cleanup' Kexi 3 removes Kross usage and moves
> towards
> > a single language-solution that happens to be JavaScript, using QtQml.
> The
> > main reason is that sandbox works there and not in Python.[1] By default
> > QtQml gives no tiny chance to access filesystem for example or run
> unwanted
> > scripts.
> >
> > There are no declared lovers of JavaScript among us, C++ hackers I think.
> > But the specifics of JavaScript is less of a problem than inherent
> > insecurity of Python's execution environment. Insecurity would manifest
> once
> > apps that use scripts get popular. The result I'd expect is very much
> like
> > perfect cross-platforms viruses.
> > This is possible if scripts are accessible with documents, which is
> > assumption of Kexi (files are meant to be user-defined apps) and in the
> > future, I believe, also Sheet's documents, if we want competitiveness.
> >
> > For that matter, also ruby and bash and perl, would be all better
> rejected
> > for the same reason.
> > Sure, there were ideas of digital signing of scripts but 1. Even tech
> people
> > do not use that (and even for emails) in general, 2. Except for Krita
> > "official" builds we're not controlling the deployment process, distros
> do
> > that, and I imagine all sort of critical issues can sooner happen e.g.
> > because of mixes responsibility. It seems that distros are able to act
> more
> > "reactionary", not as  "owners" of the software as a product. Which does
> not
> > surprise me and there's nothing to criticize.
> >
> > For Kexi <=2 (no matter what language is picked) scripting is marked as
> > having experimental status. I am not sure whether this is the case for
> > Sheets too but for Kexi there's because of such honest status we can
> assume
> > there's no disservice to users. With Kexi 3 we have ability to start
> fresh
> > and with knowledge/experience gathered in the past. Also about knowledge
> > about the user base.
> >
> > For some other contexts the choice scripting can depend on external
> > requirements. Like "industry" standards -- for Krita Python is perceived
> as
> > some kind of standard for extending graphical features. Similar opinion
> > applies for Krita itself - generic calligra-wide scripting never have
> been
> > too actively maintained and was Kross is too simple, see [2]. For the
> > record, Krita has a proof-of-concept implementation of scripting in a
> > separate repo.
> >
> > [1] Google for "Python sandbox" for detailed discussion from Python
> hackers
> > on why this is not possible and dropped idea.
> > [2] https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html
>
> Ditching Python because of sandboxing issues makes sense. That being
> said, I would use Python to access the file system from my
> spreadsheets all the time. I don't really remember what made me to
> look into scripting support in Sheets but I vaguely remember something
> merging several CSVs into a single spreadsheet.
>

Yes, data integration is one of the most useful use cases.

> In any case, if the current plan is to remove Python support, I guess
> I am better off working on removing that instead of fixing it,
> correct?
>

I give no definitive 

answer here stating that common organized approach in Calligra is a
valuable thing. Especially that resources are always limited and better to
have one effort than multiple. Sheets maintainer decides for Sheets and it
can be assumed that who codes largely decides too.

Assuming that removal of unused/unmaintained code will be decided, yes it's
better to drop such things from Calligra 3 codebase, than just disabling
the build. The code will still sit in the history anyway. After agreement
feel free to submit patches to Phabricator Calligra.git repo and/or tasks
for Calligra 3.0 Phabricator's project.

PS: I would be interested in understanding how more or less you perform
the integration/access the filesystem: do you implement routines to read
custom file formats or so? I am collecting such information for Kexi 3
scripting features.

> David E. Narvaez
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20160122/05085634/attachment.htm>