On 2021-06-27 23:49:18 -0300 (-0300), Emmanuel Arias wrote:
[...]
> if we package from PyPi, that don't contain the testsuite, that
> result in packages with any test, and that isn't good.
>
> Also, I'm not sure, but the docs aren't in PyPi, isn't?
[...]
This depends entirely on how upstream is
Hola everybody,
On 6/26/21 7:51 PM, Louis-Philippe Véronneau wrote:
> To me, the most important thing is that all packages must at least run
> the upstream testsuite when it exists (I'm planning on writing a policy
> proposal saying this after the freeze). If PyPi releases include them, I
> think
On 2021-06-26 18:51:26 -0400 (-0400), Louis-Philippe Véronneau wrote:
[...]
> To me, the most important thing is that all packages must at least
> run the upstream testsuite when it exists (I'm planning on writing
> a policy proposal saying this after the freeze). If PyPi releases
> include them,
On 2021-06-25 16 h 42, Nicholas D Steeves wrote:
> Hi Team!
>
> I feel like there is probably consensus against the use of PyPi-provided
> upstream source tarballs in preference for what will usually be a GitHub
> release tarball, so I made an MR to this effect (moderate recommendation
> rather
On Fri, 25 Jun 2021 at 18:29:19 -0400, Nicholas D Steeves wrote:
> Take for example the
> case where upstream exclusively supports a Flatpak and/or Snap
> package...
Flatpak and Snap aren't source package formats (like Autotools "make dist"
or Meson "meson dist" or Python sdist), they're binary
On 2021-06-26 02:04, Paul Wise wrote:
> I would like to see #2 split into two separate tarballs, one for the
> exact copy of the git tree and one containing the data about the other
> tarball. Then use dpkg-source v3 secondary tarballs to add the data
> about the git repo to the Debian source
File names on PyPI are write once. Once a specific file name has been used it
can never be used again (even if the entire project was deleted and recreated).
Projects can delete uploaded files (and as mentioned they can be yanked, but
yanking is just extra metadata beside the file), but file
On 2021-06-26 02:04:40 + (+), Paul Wise wrote:
> On Fri, Jun 25, 2021 at 11:42 PM Jeremy Stanley wrote:
[..]
> > 2. Cryptographically signed tarballs of the file tree corresponding
> >to a tag in the Git repository, with versioning, revision
> >history, release notes and authorship
On Fri, Jun 25, 2021 at 07:01:39PM -0400, Nicholas D Steeves wrote:
> Does PyPi provide immutable releases?
From experience, I can tell you that yes, releases cannot be overwritten,
but they can be "yanked". Pypi states that a yanked release is:
"A release that is always ignored by an
On Fri, Jun 25, 2021 at 11:42 PM Jeremy Stanley wrote:
> 1. Cryptographically signed tags in a Git repository, with
>versioning, revision history, release notes and authorship either
>embedded within or tied to the Git metadata.
>
> 2. Cryptographically signed tarballs of the file tree
On Fri, Jun 25, 2021 at 9:17 PM Jeremy Stanley wrote:
> The proposal is somewhat akin to saying that a
> tarball created via `make dist` is unsuitable for packaging.
This is definitely true; they generally contain generated files
(configure, Makefile.in) and embedded code copies (missing
On Fri, Jun 25, 2021 at 8:49 PM Nicholas D Steeves wrote:
> I feel like there is probably consensus against the use of PyPi-provided
> upstream source tarballs in preference for what will usually be a GitHub
> release tarball
I think this should be a Debian-wide default and documented in Debian
Hi Jeremy!
Wow, you've given me a lot to think about. Thank you :-)
Yes, I agree with you that my MR doesn't adequately address the much
more heterogeneous reality. (and is also indelicate, lacks nuance, etc)
I'll take a day or two to think about this, and also to take into
account what
On 2021-06-25 19:01:39 -0400 (-0400), Nicholas D Steeves wrote:
[...]
> And yes, I agree moderate is better, but I must sadly confess
> ignorance to the technical reasons why PyPI is sometimes more
> appropriate. Without technical reasons it seems like a case of
> ideological compromise (based on
On 2021-06-25 18:29:19 -0400 (-0400), Nicholas D Steeves wrote:
> A recommendation is non-binding, and the intent of this proposal is to
> say that the most "sourceful" form of source is the *most* suitable for
> Debian packages. The inverse of this is that `make dist` is less
> suitable for
Hi Simon,
Simon McVittie writes:
> On Fri, 25 Jun 2021 at 16:42:42 -0400, Nicholas D Steeves wrote:
>> I feel like there is probably consensus against the use of PyPi-provided
>> upstream source tarballs in preference for what will usually be a GitHub
>> release tarball
>
> This is not really
Hi Scott,
Scott Talbert writes:
> On Fri, 25 Jun 2021, Jeremy Stanley wrote:
>
[snip]
> I tend to agree about PyPI being the official releases for a lot of
> projects. "GitHub tarballs" also tend to include other undesirable stuff
> for distribution like upstream CI/CD configuration files,
Hi Jeremy,
Thank you for your comments, reply follows inline:
Jeremy Stanley writes:
> On 2021-06-25 16:42:42 -0400 (-0400), Nicholas D Steeves wrote:
>> I feel like there is probably consensus against the use of PyPi-provided
>> upstream source tarballs in preference for what will usually be
On Fri, 25 Jun 2021 at 16:42:42 -0400, Nicholas D Steeves wrote:
> I feel like there is probably consensus against the use of PyPi-provided
> upstream source tarballs in preference for what will usually be a GitHub
> release tarball
This is not really consistent with what devref says:
The
On Fri, 25 Jun 2021, Jeremy Stanley wrote:
I feel like there is probably consensus against the use of PyPi-provided
upstream source tarballs in preference for what will usually be a GitHub
release tarball, so I made an MR to this effect (moderate recommendation
rather than a "must" directive):
On 2021-06-25 16:42:42 -0400 (-0400), Nicholas D Steeves wrote:
> I feel like there is probably consensus against the use of PyPi-provided
> upstream source tarballs in preference for what will usually be a GitHub
> release tarball, so I made an MR to this effect (moderate recommendation
> rather
Hi Team!
I feel like there is probably consensus against the use of PyPi-provided
upstream source tarballs in preference for what will usually be a GitHub
release tarball, so I made an MR to this effect (moderate recommendation
rather than a "must" directive):
22 matches
Mail list logo
