[Good replies from Donald, Paul, et al already, but rather than
replying to individual points, I figure it's best to just respond to
Chris's original question with my own thoughts]
On 23 July 2016 at 01:47, Chris Barker - NOAA Federal
wrote:
> Right now, the barrier to
A more conservative approach might be to flag high-risk, typo-prone package
names as requiring moderator approval to register. Some combination of
looking at common 404s (or whatever happens when a client asks for a
non-existent package), some string metrics (Levenshtein, Jaro, whatever) to
an
On 07/22/2016 12:39 PM, Donald Stufft wrote:
On Jul 22, 2016, at 11:47 AM, Chris Barker - NOAA Federal
wrote:
If the core devs think it's fine and dandy like it is, we can all stop
talking about it.
I think they’re certainly a problem. The current solutions that have
We've been discussing here at least two different problems related to
package maintainership:
1. Abandoned/no-longer-maintained, but previously useful packages
2. namespace and package idea space pollution due to tests/aborted
attempts/packaginginexperience.
I don't have a good idea about 1,
> On Jul 22, 2016, at 11:47 AM, Chris Barker - NOAA Federal
> wrote:
>
>
> If the core devs think it's fine and dandy like it is, we can all stop
> talking about it.
I think they’re certainly a problem. The current solutions that have been
proposed have their own
> On Jul 22, 2016, at 11:47 AM, Chris Barker - NOAA Federal
> wrote:
>
>
> If the core devs think it's fine and dandy like it is, we can all stop
> talking about it.
I think they’re certainly a problem. The current solutions that have been
proposed have their own
On 22 July 2016 at 16:47, Chris Barker - NOAA Federal
wrote:
> But it's totally unclear to me whether the core devs don't think these
> are problems worth addressing, or think they can only be addresses
> with major effort that no one has time for.
Speaking for myself,
Getting to this thread late, but it didn't seem that was resolved in
the least, so I'll as my $0.02
> That overall got me thinking about namespace pollution in pip, that
> once something is pushed in, it's like to stay there forever.
This REALLY is a problem, and one that will only get worse. It
On 20 July 2016 at 14:13, Wes Turner wrote:
>> - near-zero additional maintenance overhead for tooling maintainers
>> that don't care about the semantic web
>
> Is it of value to link CVE reports with the package metadata?
On PyPI, the main value would be in publisher
I think you're right that we should identify the stakeholders here.
Which clients consume PyPI JSON?
@dstufft
Is there a User Agent report for the PyPI and the warehouse legacy JSON
views?
... https://code.activestate.com/lists/python-distutils-sig/25457/
Are there still pending metadata PEPs
On 20 July 2016 at 01:41, Wes Turner wrote:
> A view producing JSONLD.
>
> Probably right about here:
> https://github.com/pypa/warehouse/blob/master/warehouse/packaging/views.py
Then stop trying to guilt other people into implementing JSON-LD
support for you, and submit a
On Jul 19, 2016 8:44 AM, "Nick Coghlan" wrote:
>
> On 19 July 2016 at 18:13, Wes Turner wrote:
> > so, there's a need for specifying the {PyPI} package URI in setup.py
>
> Not really - tools can make a reasonable guess about the source PyPI
> URL based
On 19 July 2016 at 18:13, Wes Turner wrote:
> so, there's a need for specifying the {PyPI} package URI in setup.py
Not really - tools can make a reasonable guess about the source PyPI
URL based purely on the name and version. For non-PyPI hosted
packages, the extra piece of
On 19 July 2016 at 17:25, Wes Turner wrote:
> On Jul 19, 2016 2:37 AM, "Nick Coghlan" wrote:
>> Given that we already have services like libraries.io and
>> release-monitoring.org for ecosystem independent tracking of upstream
>> releases, they're more
so, there's a need for specifying the {PyPI} package URI in setup.py
and then generating meta.jsonld from setup.py
and then generating JSONLD in a warehouse/pypa view; because that's where
they keep the actual metadara (package platform versions, checksums,
potentially supersededBy redirects)
On Jul 19, 2016 2:37 AM, "Nick Coghlan" wrote:
>
> On 18 July 2016 at 02:56, Wes Turner wrote:
> > If you have an alternate way to represent a graph with JSON, which is
> > indexable as as RDF named graph quads and cryptographically signable
> >
On 18 July 2016 at 02:56, Wes Turner wrote:
> If you have an alternate way to represent a graph with JSON, which is
> indexable as as RDF named graph quads and cryptographically signable
> irrespective of data ordering or representation format (RDFa, JSONLD) with
>
If you have an alternate way to represent a graph with JSON, which is
indexable as as RDF named graph quads and cryptographically signable
irrespective of data ordering or representation format (RDFa, JSONLD) with
ld-signatures,
I'd be interested to hear how said format solves for that problem.
On 16 July 2016 at 23:47, Wes Turner wrote:
> So, there could be RDFa in the project detail pages and a JSONLD key/dict in
> the project metadata indicating this community-reviewed edge or edges.
Wes, once again, please stop attempting to inject JSON-LD into every
metadata
On Jul 16, 2016 3:36 AM, "Nick Coghlan" wrote:
>
> On 15 July 2016 at 23:59, Thomas Kluyver wrote:
> > On Fri, Jul 15, 2016, at 01:25 AM, Donald Stufft wrote:
> >
> > Off the top of my head I can only really think of PIL, and *maybe* suds.
> > Unless
On 15 July 2016 at 23:59, Thomas Kluyver wrote:
> On Fri, Jul 15, 2016, at 01:25 AM, Donald Stufft wrote:
>
> Off the top of my head I can only really think of PIL, and *maybe* suds.
> Unless there’s a lot of these maybe all we really need is a policy for when
>
On Fri, Jul 15, 2016, at 01:25 AM, Donald Stufft wrote:
> Off the top of my head I can only really think of PIL, and *maybe*
> suds. Unless there’s a lot of these maybe all we really need is a
> policy for when administrators can/will edit the page to direct people
> towards a different project or
Message-
From: "Donald Stufft" <don...@stufft.io>
Sent: 7/14/2016 17:25
To: "Steve Dower" <steve.do...@python.org>
Cc: "Daniel D. Beck" <dan...@ddbeck.com>; "distutils-sig"
<distutils-sig@python.org>
Subject: Re: [Distutils] Outda
> On Jul 14, 2016, at 8:19 PM, Steve Dower wrote:
>
> I'm still keen to find a way to redirect people to useful forks or
> alternative packages that doesn't require thousands of mentions at
> conferences for all time ala PIL.
I’m not opposed to this but we’ll want to
rg>
Cc: "Daniel D. Beck" <dan...@ddbeck.com>; "distutils-sig"
<distutils-sig@python.org>
Subject: Re: [Distutils] Outdated packages on pypi
> On Jul 14, 2016, at 6:51 PM, Steve Dower <steve.do...@python.org> wrote:
>
> On 14Jul2016 0619, Daniel D.
> On Jul 14, 2016, at 6:51 PM, Steve Dower wrote:
>
> On 14Jul2016 0619, Daniel D. Beck wrote:
>> Free-form, user-generated content on PyPI would become a pathway for
>> harassment and abuse. Introducing user-generated content on PyPI would
>> necessarily put an
On Fri, Jul 15, 2016 at 1:51 AM, Steve Dower wrote:
> This is why I listed a set of restrictions to help prevent that:
>
> * 140 chars (flexible, but short enough to prevent rants)
>
Did you mean to write "provoke" instead of "prevent"? If we can learn one
thing from
On 14Jul2016 0619, Daniel D. Beck wrote:
Free-form, user-generated content on PyPI would become a pathway for
harassment and abuse. Introducing user-generated content on PyPI would
necessarily put an emotional burden on package maintainers in addition
to the maintenance burden (unless PyPI
On Thu, Jul 14, 2016 at 11:57 AM, Wes Turner wrote:
> Adding an embedded JS comments widget does/would add some additional
> maintenance burden (because user-generated content).
Free-form, user-generated content on PyPI would become a pathway for
harassment and abuse.
There are types to describe this graph.
Thing > CreativeWork > SoftwareApplication
CreativeWork.comment r: [Comment]
http://schema.org/SoftwareApplication
http://schema.org/Comment
( #PEP426JSONLD because this is a graph of SoftwareApplication(s); now with
TOML metadata )
There could be edge
On 13Jul2016 1456, Glyph Lefkowitz wrote:
On Jul 13, 2016, at 1:54 PM, Steve Dower > wrote:
Possibly such user-contributed content would be valuable anyway
https://alternativeto.net but for PyPI? :)
Or just more general
> On Jul 13, 2016, at 1:54 PM, Steve Dower wrote:
>
> Possibly such user-contributed content would be valuable anyway
https://alternativeto.net but for PyPI? :)
-glyph___
Distutils-SIG maillist - Distutils-SIG@python.org
On 13Jul2016 1252, Glyph Lefkowitz wrote:
The primary thing would be to have a banner on the page and a warning
from `pip install´. Those of us close to the heart of the Python
community already have various ways of reading the tea leaves to know
that things are likely to be unmaintained or
> On Jul 12, 2016, at 9:54 PM, Donald Stufft wrote:
>
>
>> On Jul 12, 2016, at 4:45 PM, Glyph Lefkowitz wrote:
>>
>> My feeling is that there should be a "dead man's switch" sort of mechanism
>> for this. Require manual intervention from at least
> On Jul 13, 2016, at 2:08 PM, Dima Tisnek wrote:
>
> I'd rather see something similar to Linux distributions where there's
> a curated repository "core" and a few semi-official, like "extra" and
> "community," and for some, "testing."
> A name foobar resolves to core/foobar-
On 13 July 2016 at 19:08, Dima Tisnek wrote:
> I'd rather see something similar to Linux distributions where there's
> a curated repository "core" and a few semi-official, like "extra" and
> "community," and for some, "testing."
> A name foobar resolves to core/foobar- if that
I came across a package by accident.
A mate made a reasonable mistake typing in a pip command, and
something odd got installed.
For a moment I even suspected that package in question was some kind
of malware, so I went to download it manually (not via pip install),
and realised that the package
Well said.
IMO, package names shouldn't be reused. Also, IMO, we have a
namespace problem, for which there's a common solution that we avoid
(domain based names, which can also be reused, but ...).
OTOH, here's an idea. What if in addition to the project name, we also
assigned a unique id. When
On Tue, Jul 12, 2016 at 7:55 AM, Dima Tisnek wrote:
> Hi all,
>
> Is anyone working on pruning old packages from pypi?
>
> I found something last updated in 2014, which, looking at the source
> appears half-done.
> Github link doesn't work any longer, no description, etc.
>
> I
On Tue, 12 Jul 2016 at 21:54 Donald Stufft wrote:
>
> > On Jul 12, 2016, at 4:45 PM, Glyph Lefkowitz
> wrote:
> >
> > My feeling is that there should be a "dead man's switch" sort of
> mechanism for this. Require manual intervention from at least one
> On Jul 12, 2016, at 4:45 PM, Glyph Lefkowitz wrote:
>
> My feeling is that there should be a "dead man's switch" sort of mechanism
> for this. Require manual intervention from at least one package owner at
> least once a year. I believe if you dig around in the
> On Jul 12, 2016, at 4:55 AM, Dima Tisnek wrote:
>
> Hi all,
>
> Is anyone working on pruning old packages from pypi?
>
> I found something last updated in 2014, which, looking at the source
> appears half-done.
> Github link doesn't work any longer, no description, etc.
>
Hi all,
Is anyone working on pruning old packages from pypi?
I found something last updated in 2014, which, looking at the source
appears half-done.
Github link doesn't work any longer, no description, etc.
I managed to find author's email address out of band, and he responded
that he can't
43 matches
Mail list logo