Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #9883 > unrolled thread

pycharm package in debian

Back to article view | Back to linux.debian.maint.python

Contents

  pycharm package in debian kamaraju kusumanchi <raju.mailinglists@gmail.com> - 2017-09-30 14:30 +0200
    Re: pycharm package in debian Yaroslav Halchenko <yoh@onerussian.com> - 2017-09-30 15:40 +0200
    Re: pycharm package in debian Julien Puydt <julien.puydt@laposte.net> - 2017-09-30 16:40 +0200
      Re: pycharm package in debian Paul Wise <pabs@debian.org> - 2017-10-01 03:40 +0200
        Re: pycharm package in debian Ghislain Vaillant <ghisvail@gmail.com> - 2017-10-01 09:30 +0200
          Re: pycharm package in debian Paul Wise <pabs@debian.org> - 2017-10-01 09:40 +0200
            Re: pycharm package in debian Ghislain Vaillant <ghisvail@gmail.com> - 2017-10-01 09:50 +0200
              Re: pycharm package in debian Ben Finney <bignose@debian.org> - 2017-10-01 10:50 +0200
                Re: pycharm package in debian Ghislain Vaillant <ghisvail@gmail.com> - 2017-10-01 11:10 +0200
                  Re: pycharm package in debian Ben Finney <bignose@debian.org> - 2017-10-01 11:50 +0200
              Re: pycharm package in debian Thomas Goirand <zigo@debian.org> - 2017-10-01 21:40 +0200
                Re: pycharm package in debian Ghislain Vaillant <ghisvail@gmail.com> - 2017-10-01 22:10 +0200
                Re: pycharm package in debian Matthias Klose <doko@debian.org> - 2017-10-02 00:00 +0200
                  Re: pycharm package in debian Thomas Goirand <zigo@debian.org> - 2017-10-02 10:40 +0200
                    Re: pycharm package in debian "W. Martin Borgert" <debacle@debian.org> - 2017-10-02 10:50 +0200
                    Re: pycharm package in debian Diane Trout <diane@ghic.org> - 2017-10-04 23:20 +0200
                      Re: pycharm package in debian Simon McVittie <smcv@debian.org> - 2017-10-04 23:50 +0200
                        Re: pycharm package in debian Diane Trout <diane@ghic.org> - 2017-10-05 01:10 +0200
          Re: pycharm package in debian "W. Martin Borgert" <debacle@debian.org> - 2017-10-01 17:00 +0200
            Re: pycharm package in debian Ghislain Vaillant <ghisvail@gmail.com> - 2017-10-01 18:20 +0200
              Re: pycharm package in debian "W. Martin Borgert" <debacle@debian.org> - 2017-10-01 18:40 +0200
                Re: pycharm package in debian Ben Finney <bignose@debian.org> - 2017-10-02 00:10 +0200
                Re: pycharm package in debian Andrey Rahmatullin <wrar@debian.org> - 2017-10-02 00:10 +0200
            Re: pycharm package in debian Andrey Rahmatullin <wrar@debian.org> - 2017-10-01 20:20 +0200
              Re: pycharm package in debian "W. Martin Borgert" <debacle@debian.org> - 2017-10-01 23:20 +0200
          snap in debian Brian May <bam@debian.org> - 2017-10-01 22:50 +0200
            Re: snap in debian Michael Hudson-Doyle <michael.hudson@canonical.com> - 2017-10-04 22:40 +0200
              Re: snap in debian Brian May <bam@debian.org> - 2017-10-04 23:00 +0200
                Re: snap in debian Brian May <bam@debian.org> - 2017-10-04 23:10 +0200
                Re: snap in debian Michael Hudson-Doyle <michael.hudson@canonical.com> - 2017-10-04 23:20 +0200
                  Re: snap in debian Michael Hudson-Doyle <michael.hudson@canonical.com> - 2017-10-09 01:50 +0200
                    Re: snap in debian Michael Hudson-Doyle <michael.hudson@canonical.com> - 2017-10-09 02:20 +0200
                      Re: snap in debian Michael Hudson-Doyle <michael.hudson@canonical.com> - 2017-10-09 03:20 +0200
                        Re: snap in debian Brian May <bam@debian.org> - 2017-10-15 04:30 +0200
          Re: pycharm package in debian kamaraju kusumanchi <raju.mailinglists@gmail.com> - 2017-10-02 02:30 +0200

Page 1 of 2  [1] 2  Next page →

#9883 — pycharm package in debian

Are there any plans to make a debian package of pycharm that is part
of official debian? I used their community edition on windows 7 and it
is awesome.

thanks
-- 
Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog

[toc] | [next] | [standalone]

#9884

Fwiw I have made a pycharm-community-sloppy package available from NeuroDebian - just wrapped their distribution. Btw seems to work with open jdk just fine. Packaging for Debian proper would need some Java verse maintainer.

On September 30, 2017 8:22:56 AM EDT, kamaraju kusumanchi <raju.mailinglists@gmail.com> wrote:
>Are there any plans to make a debian package of pycharm that is part
>of official debian? I used their community edition on windows 7 and it
>is awesome.
>
>thanks

-- 
Sent from a phone which beats iPhone.

[toc] | [prev] | [next] | [standalone]

#9885

Hi,

Le 30/09/2017 à 14:22, kamaraju kusumanchi a écrit :
> Are there any plans to make a debian package of pycharm that is part
> of official debian? I used their community edition on windows 7 and it
> is awesome.

Maybe you should look at WNPP to see if someone filed a RFP or ITP, and
if not, submit a RFP yourself?

Snark on #debian-python

[toc] | [prev] | [next] | [standalone]

#9888

On Sat, Sep 30, 2017 at 10:35 PM, Julien Puydt wrote:
> Le 30/09/2017 à 14:22, kamaraju kusumanchi a écrit :
>> Are there any plans to make a debian package of pycharm that is part
>> of official debian? I used their community edition on windows 7 and it
>> is awesome.
>
> Maybe you should look at WNPP to see if someone filed a RFP or ITP, and
> if not, submit a RFP yourself?

Looks like someone attempted it but gave up, so if you would like to
do it that would be great.

https://bugs.debian.org/742394
https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#9889

On 01/10/17 02:36, Paul Wise wrote:
> On Sat, Sep 30, 2017 at 10:35 PM, Julien Puydt wrote:
>> Le 30/09/2017 à 14:22, kamaraju kusumanchi a écrit :
>>> Are there any plans to make a debian package of pycharm that is part
>>> of official debian? I used their community edition on windows 7 and it
>>> is awesome.
>>
>> Maybe you should look at WNPP to see if someone filed a RFP or ITP, and
>> if not, submit a RFP yourself?
> 
> Looks like someone attempted it but gave up, so if you would like to
> do it that would be great.
> 
> https://bugs.debian.org/742394
> https://mentors.debian.net/intro-maintainers

May I ask what would be the benefit for pycharm to be in Debian, when we 
already have the official Jetbrains Toolbox App or the snap package as 
means to install and update the application?

Ghis

[toc] | [prev] | [next] | [standalone]

#9890

On Sun, Oct 1, 2017 at 3:26 PM, Ghislain Vaillant wrote:

> May I ask what would be the benefit for pycharm to be in Debian, when we
> already have the official Jetbrains Toolbox App or the snap package as means
> to install and update the application?

I've never heard of the first of those, definitely wouldn't use the
snap package and probably not the Jetbrains thing, unless either of
them were built entirely from packages in Debian main, which I am
assuming they aren't ever going to be.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#9891

On 01/10/17 08:38, Paul Wise wrote:
> On Sun, Oct 1, 2017 at 3:26 PM, Ghislain Vaillant wrote:
> 
>> May I ask what would be the benefit for pycharm to be in Debian, when we
>> already have the official Jetbrains Toolbox App or the snap package as means
>> to install and update the application?
> 
> I've never heard of the first of those, definitely wouldn't use the
> snap package and probably not the Jetbrains thing, unless either of
> them were built entirely from packages in Debian main, which I am
> assuming they aren't ever going to be.

Sure, though I foresee the sheer amount of packaging work to get this 
sort of app in the archive to be quite a challenge, both from an initial 
packaging and on-going maintenance effort. Look at what happened with 
eclipse for instance.

Besides, rrom an end-user perspective, I can't picture anyone preferring 
the (potentially lagging) packaged version over more official means like 
the Jetbrains app or the snap package, both of which have been good at 
keeping up with updates.

Don't get me wrong, I understand the rationales from a DFSG perspective. 
I am just questioning whether users of this particular piece of software 
would particularly care.

Ghis

[toc] | [prev] | [next] | [standalone]

#9892

Ghislain Vaillant <ghisvail@gmail.com> writes:

> Don't get me wrong, I understand the rationales from a DFSG
> perspective. I am just questioning whether users of this particular
> piece of software would particularly care.

The same could be asked of many user-facing packages in Debian. Your
question, though, makes an incorrect assumption: that “users of this
particular piece of software” is a group whose membership is unaffected
by having the package in Debian.

On the contrary. Take me as a counter-example. I am not a user of this
particular piece of software, because I have little interest in judging
for myself the hundreds of user-facing applications on my system.

If it were in Debian I can then take all the assurance that brings about
freedom and maintenance, and I may indeed consider using this particular
piece of software where otherwise I would not.

So, one important reason to package a work in Debian is to *increase*
the set of people who can easily install and use it.

-- 
 \      “Pinky, are you pondering what I'm pondering?” “Uh, I think so |
  `\  Brain, but this time, you wear the tutu.” —_Pinky and The Brain_ |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#9893

[Multipart message — attachments visible in raw view] — view raw

Le 1 oct. 2017 09:49, "Ben Finney" <bignose@debian.org> a écrit :

Ghislain Vaillant <ghisvail@gmail.com> writes:

> Don't get me wrong, I understand the rationales from a DFSG
> perspective. I am just questioning whether users of this particular
> piece of software would particularly care.

The same could be asked of many user-facing packages in Debian. Your
question, though, makes an incorrect assumption: that “users of this
particular piece of software” is a group whose membership is unaffected
by having the package in Debian.

On the contrary. Take me as a counter-example. I am not a user of this
particular piece of software, because I have little interest in judging
for myself the hundreds of user-facing applications on my system.

If it were in Debian I can then take all the assurance that brings about
freedom and maintenance, and I may indeed consider using this particular
piece of software where otherwise I would not.

So, one important reason to package a work in Debian is to *increase*
the set of people who can easily install and use it.


All 3 means of installation (Jetbrain's app, snap and potentially apt) are
one-liners for the end-user. So, ease-of-use is hardly a compelling
argument.

And I don't question your initial assessment about other applications in
the archive. Hence myself mentioning eclipse earlier, as a similar package
which used to be actively maintained until the effort died out.

I am just wondering whether an effort to package pycharm would not reach
the same outcome, assuming it passes the initial import phase. The Atom IDE
for instance never did.

Ghis

[toc] | [prev] | [next] | [standalone]

#9894

Ghislain Vaillant <ghisvail@gmail.com> writes:

> All 3 means of installation (Jetbrain's app, snap and potentially apt)
> are one-liners for the end-user. So, ease-of-use is hardly a
> compelling argument.

That's not the argument I made. I am satying that there are people who
are not in the set of people who will install Snap or Flatpak or etc.,
because it's too much hassle to know whether it is free software or
whether it will work correctly with the rest of the system.

Getting the work as free software in Debian opens up the package for
installation by those people. I count myself among them.

I say this to counter the idea that there is a set of “users of this
software package” that is not affected by whether the software is in
Debian. That is false, and indeed getting the package maintained in
Debian is a way to *increase* the potential members of that set.

So, I don't find the “would users of this software package care about it
being in Debian” query not compelling, because it makes a false
assumption about the relationship.

-- 
 \        “If we ruin the Earth, there is no place else to go. This is |
  `\    not a disposable world, and we are not yet able to re-engineer |
_o__)                      other planets.” —Carl Sagan, _Cosmos_, 1980 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#9899

On 10/01/2017 09:47 AM, Ghislain Vaillant wrote:
> Besides, rrom an end-user perspective, I can't picture anyone preferring
> the (potentially lagging) packaged version over more official means like
> the Jetbrains app or the snap package, both of which have been good at
> keeping up with updates.

I definitively prefer a Debian package in main, even if it is "lagging
behind" as you said. For such a thing as an IDE, I expect it to be
mature enough so that the older version is enough for the everyday use.
And I would feel safer than using any random snap package. Who knows
what security issue is in there and what security policy and procedure
(if any) is in place.

> Don't get me wrong, I understand the rationales from a DFSG perspective.
> I am just questioning whether users of this particular piece of software
> would particularly care.

I at least would care. And would very much welcome anyone doing the work
of packaging and maintaining this kind of software.

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#9900

On 01/10/17 20:33, Thomas Goirand wrote:
> On 10/01/2017 09:47 AM, Ghislain Vaillant wrote:
>> Besides, rrom an end-user perspective, I can't picture anyone preferring
>> the (potentially lagging) packaged version over more official means like
>> the Jetbrains app or the snap package, both of which have been good at
>> keeping up with updates.
> 
> I definitively prefer a Debian package in main, even if it is "lagging
> behind" as you said. For such a thing as an IDE, I expect it to be
> mature enough so that the older version is enough for the everyday use.
> And I would feel safer than using any random snap package. Who knows
> what security issue is in there and what security policy and procedure
> (if any) is in place.

You guessed it there are none. Confinement is disabled for the pycharm 
snap, so it behaves like any other application installed via a deb package.

>> Don't get me wrong, I understand the rationales from a DFSG perspective.
>> I am just questioning whether users of this particular piece of software
>> would particularly care.
> 
> I at least would care. And would very much welcome anyone doing the work
> of packaging and maintaining this kind of software.

Don't get me wrong, I would welcome such effort too. I just wanted to 
emphasize the implication and level of commitment that such effort would 
require. We have been there with eclipse and atom, the former is (still) 
lagging quite badly, and the latter was stopped at the initial packaging 
stage.

Ghis

[toc] | [prev] | [next] | [standalone]

#9903

On 01.10.2017 21:33, Thomas Goirand wrote:
> On 10/01/2017 09:47 AM, Ghislain Vaillant wrote:
>> Besides, rrom an end-user perspective, I can't picture anyone preferring
>> the (potentially lagging) packaged version over more official means like
>> the Jetbrains app or the snap package, both of which have been good at
>> keeping up with updates.
> 
> I definitively prefer a Debian package in main, even if it is "lagging
> behind" as you said. For such a thing as an IDE, I expect it to be
> mature enough so that the older version is enough for the everyday use.
> And I would feel safer than using any random snap package. Who knows
> what security issue is in there and what security policy and procedure
> (if any) is in place.

who says that a "lagging behind" package doesn't have any security issues? If
the package is lagging behind, how do you know that security updates aren't
lagging behind either...

Do you want point users to the five year lagging behind eclipse package in Debian?

[toc] | [prev] | [next] | [standalone]

#9907

On 10/01/2017 11:50 PM, Matthias Klose wrote:
> On 01.10.2017 21:33, Thomas Goirand wrote:
>> On 10/01/2017 09:47 AM, Ghislain Vaillant wrote:
>>> Besides, rrom an end-user perspective, I can't picture anyone preferring
>>> the (potentially lagging) packaged version over more official means like
>>> the Jetbrains app or the snap package, both of which have been good at
>>> keeping up with updates.
>>
>> I definitively prefer a Debian package in main, even if it is "lagging
>> behind" as you said. For such a thing as an IDE, I expect it to be
>> mature enough so that the older version is enough for the everyday use.
>> And I would feel safer than using any random snap package. Who knows
>> what security issue is in there and what security policy and procedure
>> (if any) is in place.
> 
> who says that a "lagging behind" package doesn't have any security issues? If
> the package is lagging behind, how do you know that security updates aren't
> lagging behind either...

As this is Debian, I do expect that at least, I can read the security
tracker to see the current status. For a snap package, I wouldn't know
how to audit it.

> Do you want point users to the five year lagging behind eclipse package in Debian?

Why 5 years? We do release stable approx every 2.5 years...

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#9908

On 2017-10-02 10:37, Thomas Goirand wrote:
> On 10/01/2017 11:50 PM, Matthias Klose wrote:
> > Do you want point users to the five year lagging behind eclipse package in Debian?
>
> Why 5 years? We do release stable approx every 2.5 years...

5 years minus 12 days:
Eclipse 3.8.1 has been uploaded to Debian on 2012-10-14.

Cheers

[toc] | [prev] | [next] | [standalone]

#9916

> > who says that a "lagging behind" package doesn't have any security
> > issues? If
> > the package is lagging behind, how do you know that security
> > updates aren't
> > lagging behind either...
> 
> As this is Debian, I do expect that at least, I can read the security
> tracker to see the current status. For a snap package, I wouldn't
> know
> how to audit it.

I do wish that these third party app systems like conda, snappy or
flatpak would include metadata like AppStream or DOAP.

It would be really convenient to have one tool that could audit a
system for out of date packages, and for our bug reporting tools to be
able to direct users to the responsible party for a third party
installation.

I can see that GNOME software has some visibility into what valve's
steam is doing so it's at least theoretically possible.

Diane

[toc] | [prev] | [next] | [standalone]

#9918

On Wed, 04 Oct 2017 at 14:11:02 -0700, Diane Trout wrote:
> I do wish that these third party app systems like conda, snappy or
> flatpak would include metadata like AppStream or DOAP.

Flatpak already does.

Flatpak apps nearly always include AppStream metadata, which Flatpak's
repository maintenance tool aggregates into AppStream distro XML in
special branches in the repository for easier access (analogous to how dak
aggregates dpkg metadata into dists/**/Packages, and AppStream metadata
into DEP-11 YAML). Any Flatpak package that doesn't have AppStream
metadata won't appear in GNOME Software (and probably other GUIs), and so
will only be installable via the CLI or a web link to a .flatpakref file.

DOAP isn't really for this: it provides developer-facing information
about projects (source packages), whereas AppStream provides user-facing
information about apps (binary packages). If AppStream is like dpkg
binary package metadata (control.tar.*), then DOAP is more like the
first paragraph of debian/control in a dpkg source package.

Regards,
    smcv

[toc] | [prev] | [next] | [standalone]

#9919

On Wed, 2017-10-04 at 22:47 +0100, Simon McVittie wrote:
> On Wed, 04 Oct 2017 at 14:11:02 -0700, Diane Trout wrote:
> > I do wish that these third party app systems like conda, snappy or
> > flatpak would include metadata like AppStream or DOAP.
> 
> Flatpak already does.

Given both flatpak & appstream came out of GNOME I suspected they'd
work together.

I haven't read the AppStream spec yet, so wasn't sure if it had bug-
contact information.

I suspected in some python cases DOAP style information from setup.py
might make it to conda application metadata.

Diane

[toc] | [prev] | [next] | [standalone]

#9895

On 2017-10-01 08:26, Ghislain Vaillant wrote:
> May I ask what would be the benefit for pycharm to be in Debian, when we
> already have the official Jetbrains Toolbox App or the snap package as means
> to install and update the application?

I usually start to use software, when it arrives in Debian.
Or I package it. If there is some snap or other third party
package, I'm unsure how to work with it:

How to install? How to uninstall? How to report bugs and to
whom? How to download the source code and rebuild it? Is it
DFSG-free anyway? (Does it already build reproducible?)

There is nothing wrong with having snap or other packages
available, but I'm not their target audience. But I'm an Emacs
- and vi! - user anyway :~)

Another question is, how much work it will be and whether it is
worth the effort, esp. permanent maintenance. But if somebody
wants to do it, why not?

Cheers

[toc] | [prev] | [next] | [standalone]

#9896

[Multipart message — attachments visible in raw view] — view raw

Le 1 oct. 2017 15:53, "W. Martin Borgert" <debacle@debian.org> a écrit :

On 2017-10-01 08:26, Ghislain Vaillant wrote:
> May I ask what would be the benefit for pycharm to be in Debian, when we
> already have the official Jetbrains Toolbox App or the snap package as
means
> to install and update the application?

I usually start to use software, when it arrives in Debian.
Or I package it. If there is some snap or other third party
package, I'm unsure how to work with it:


You mean the average user cannot use Google? The installation instructions
on Jetbrain's website sounds pretty clear to me, so is installing a snap
package.


How to install? How to uninstall? How to report bugs and to
whom? How to download the source code and rebuild it? Is it
DFSG-free anyway? (Does it already build reproducible?)


You and I care about these things as Debian contributors. The average Joe
however usually does not.


There is nothing wrong with having snap or other packages
available, but I'm not their target audience. But I'm an Emacs
- and vi! - user anyway :~)


Whatever works for you. Actually, vim can be turned into a fine Python
editor.


Another question is, how much work it will be and whether it is
worth the effort, esp. permanent maintenance. But if somebody
wants to do it, why not?


Most likely a lot. We are talking about a large application with probably
quite a few dependencies in Java / Kotlin.

Why not? Because failure to commit to regular updates would feed the
current narrative that Debian ships old and loosely maintained software.
Especially when there are other means of installing the software which are
officially documented upstream.

I have been there with packages I personally maintain (spyder for
instance), and I am raising these concerns out of my own experience and
feedback from existing users. Feel free to disregard.

Ghis

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.maint.python

csiph-web