> On Aug 4, 2018, at 5:36 AM, Nick Coghlan wrote:
>
> I don't think there are any predefined helpers in fpm for that kind of
> model though, so you'd likely need some additional automation around
> setting up auto-generation of certbot-plugin packages (whereas certbot
> itself could likely use
[Nick wrote:]
>>> However, there *are* folks that have been working on allowing
>>> applications to be defined primarily as Python projects, and then have
>>> the creation of wrapper native installers be a pushbutton exercise,
>>> rather than requiring careful human handholding.
[Nathaniel
Yw!
* Pytest, tox, and devpi handle plugins with pluggy; which works with OS
and Python package installs AFAICT:
https://pluggy.readthedocs.io/en/latest/
* IDK what's needed to remove a package from a repo because it's
dangerously out of date.
* Arrow recently gained lots of
>> On Jul 24, 2018, at 4:36 AM, Nick Coghlan wrote:
>>
>> However, there *are* folks that have been working on allowing
>> applications to be defined primarily as Python projects, and then have
>> the creation of wrapper native installers be a pushbutton exercise,
>> rather than requiring
Took a minute more to read the gdoc link.
The CI build should produce every {OS,} package as a build artifact (along
with coverage and static analysis reports). #goeswithoutsaying
Someone can probably point to a good GitLab CI config that produces all of
the requisite artifacts and uploads them
It's generally easiest to find a maintainer who has an established track
record to adopt the project.
On Sat, Jul 28, 2018 at 11:53 AM, wrote:
> Nathaniel Smith wrote:
> > I love Debian. I've been a loyal user for twenty years. But Debian is
> > really bad at coping with software that needs to
Nathaniel Smith wrote:
> I love Debian. I've been a loyal user for twenty years. But Debian is
> really bad at coping with software that needs to react quickly to changing
> external conditions, or that depends on a tight feedback loop between users
> and developers. (Indeed, Debian's whole
>> If we didn’t want to trust any binaries built by someone else or
proprietary code, how much work would that be?
- Docker Notary (The Update Framework)
- PEP 458, PEP 480 (TUF)
- Host GPG .asc(s) for things you just found
## To build the whole toolchain yourself?
Build, Package, Install,
On Thu, Jul 26, 2018, 05:48 Ben Finney via Distutils-SIG <
distutils-sig@python.org> wrote:
> Brad Warren writes:
>
> > Our main use case has been the long tail of individuals or small teams
> > of sysadmins who maintain servers and need or want help and automation
> > around maintaining a
As a heavy user of certbot myself across numerous systems I would echo Nick and
others’ suggestions about native packaging. Third party tools and docker
containers are basically non starters.
Dan Ryan // pipenv maintainer
gh: @techalchemy
> On Jul 26, 2018, at 11:30 AM, Chris Barker - NOAA
I agree that you are probably best off integrating with the system
packaging system in this case.
But if you do want to deploy and app with all its dependencies in a
controlled environment, conda constructor May make that easy:
https://github.com/conda/constructor
-CHB
Sent from my iPhone
On 25 July 2018 at 12:39, Nathaniel Smith wrote:
>> On Jul 24, 2018, at 4:36 AM, Nick Coghlan wrote:
>>
>> However, there *are* folks that have been working on allowing
>> applications to be defined primarily as Python projects, and then have
>> the creation of wrapper native installers be a
Brad Warren writes:
> Wow! Thanks for all the feedback everyone.
Thank you for seeking it, and for the work on making Certbot viable.
> > On Jul 23, 2018, at 11:10 PM, James Bennett wrote:
> >
> > On Mon, Jul 23, 2018 at 8:17 PM, Alex Walters
> > wrote:
> > As a user of certbot, docker,
On Tue, Jul 24, 2018 at 7:39 PM, Nathaniel Smith wrote:
> On Tue, Jul 24, 2018 at 5:48 PM, Brad Warren wrote:
>>
>> Not wanting to install a lot of extra software to use Certbot is certainly
>> fair and we’d obviously prefer our packaging solution to be as lightweight
>> as possible. Thanks for
On Tue, Jul 24, 2018 at 5:48 PM, Brad Warren wrote:
> Do you know if our approach to using setuptools entry_points to find plugins
> will work [with conda]? This is described at
> https://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins.
Yes,
On Tue, Jul 24, 2018 at 5:48 PM, Brad Warren wrote:
> On Jul 23, 2018, at 6:52 PM, Chris Jerdonek
> wrote:
>
> 2) I don't know how Certbot is architected, but would it be possible
> to put the "meat" of Certbot inside a Docker container (ideally
> including most of the non-Python dependencies),
Wow! Thanks for all the feedback everyone.
> On Jul 23, 2018, at 6:52 PM, Chris Jerdonek wrote:
>
> 1) Can you list in the document the non-Python dependencies and what
> they're used for to give people an idea?
Done! I added this to the “Certbot Background” section at the top of the
document.
On 24 July 2018 at 16:10, James Bennett wrote:
> On Mon, Jul 23, 2018 at 8:17 PM, Alex Walters
> wrote:
>>
>> As a user of certbot, docker, conda, nix, and guix are non-starters. I'm
>> not depending on those tools for my production server (and while docker may
>> be a dependency for some
I think administrators should only install native packages, and thus I
recommend having a solution that can build native packages. Consider FPM, a
tool for creating native packages. It can create native packages from
virtualenv environments.
On Mon, Jul 23, 2018 at 8:17 PM, Alex Walters
wrote:
> As a user of certbot, docker, conda, nix, and guix are non-starters. I'm
> not depending on those tools for my production server (and while docker may
> be a dependency for some people, that is hardly universal). Adding
> heavyweight
On Tue, 24 Jul 2018, 02:47 Brad Warren, wrote:
> It was suggested to me that I post to this list to see if anyone was
> interested in offering advice for how we should approach this. Of course,
> Certbot is written entirely in Python.
>
A few days ago, someone posted here about XAR, might
> -Original Message-
> From: Nathaniel Smith
> Sent: Monday, July 23, 2018 10:31 PM
> To: Brad Warren
> Cc: distutils-sig
> Subject: [Distutils] Re: Packaging Advice for EFF's Certbot
>
>
> Reading the problem description at the top of your d
Thanks Nathaniel for the mention of conda.
> How will separately distributed plugins work?
Conda is based on a unix-like filesystem layout. There's a notion of a
"prefix", which on linux systems is something like /usr or /usr/local.
This can exist anywhere with conda, but there's a lib, bin,
On Mon, Jul 23, 2018 at 4:31 PM, Brad Warren wrote:
> Hi!
>
> I work at the Electronic Frontier Foundation on Certbot which is the most
> popular end user application for obtaining and installing SSL/TLS
> certificates from Let’s Encrypt. Over the past few years, distributing
> Certbot has been
I've read through your document. The question is interesting. You have
exactly the same bootstrapping problem that pip has. If I were in your
shoes here's how I would architect a solution:
1 - If you can shift your dependencies to be pure python, do it. If you
can't, stop distributing
Hi,
Interesting write-up! A couple comments / questions:
1) Can you list in the document the non-Python dependencies and what
they're used for to give people an idea?
2) I don't know how Certbot is architected, but would it be possible
to put the "meat" of Certbot inside a Docker container
26 matches
Mail list logo
