Having a "less complete" configuration for a project
I'm building a project that allows users to create files and directory structures from static data. The core of the project will be a command line API that includes a number of features that depend on 3rd party libraries. But I can see the core of the project being useful for smaller tasks, for example generating test data. So what I'd like is to have the "standard" installation "pip install myproj" build the full application, but have a way to specify (for example in a tox config) that only the core library, without the larger dependencies, be installed. Doing this the other way round is easy using extras: pip install myproj -> installs myproj and core dependencies pip install myproj[cmdline] -> installs the above, plus jinja2, click, ... But the problem with this approach is that "normal users" need to know to specify the extra. Is it possible to switch this round somehow, so that I have an "extra" that *removes* some of the dependencies? (I could have 2 projects, a core one and a cmdline one that depends on the first and adds the command-line API. I don't really like that option, though, not least because it means maintaining 2 projects rather than one, so I'm exploring whether there are other ways of achieving the objective). Any thoughts on how I could do this? Paul
On 12 October 2014 21:38, Paul Moore <p.f.moore@gmail.com> wrote:
I'm building a project that allows users to create files and directory structures from static data. The core of the project will be a command line API that includes a number of features that depend on 3rd party libraries. But I can see the core of the project being useful for smaller tasks, for example generating test data. So what I'd like is to have the "standard" installation "pip install myproj" build the full application, but have a way to specify (for example in a tox config) that only the core library, without the larger dependencies, be installed.
Doing this the other way round is easy using extras:
pip install myproj -> installs myproj and core dependencies pip install myproj[cmdline] -> installs the above, plus jinja2, click, ...
But the problem with this approach is that "normal users" need to know to specify the extra.
Is it possible to switch this round somehow, so that I have an "extra" that *removes* some of the dependencies?
(I could have 2 projects, a core one and a cmdline one that depends on the first and adds the command-line API. I don't really like that option, though, not least because it means maintaining 2 projects rather than one, so I'm exploring whether there are other ways of achieving the objective).
Any thoughts on how I could do this?
I don't know of any current way to do it, and even the more flexible extras notation in PEP 426 doesn't quite get you there. The closest it currently allows is "pip install myproj[-,core]". The "-" disables installing the default dependencies, but it *also* disables installing the distribution itself. It would be possible to extend that to "pip install myproj[-,:self:,core]", where ":self:" would be a new implicit extra for installing the project itself (to go along with the currently proposed implicit extras for ":meta:", ":run:", ":build:", ":test:", and ":dev:" to indicate which dependency lists to process). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12 October 2014 21:54, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 12 October 2014 21:38, Paul Moore <p.f.moore@gmail.com> wrote:
Is it possible to switch this round somehow, so that I have an "extra" that *removes* some of the dependencies?
(I could have 2 projects, a core one and a cmdline one that depends on the first and adds the command-line API. I don't really like that option, though, not least because it means maintaining 2 projects rather than one, so I'm exploring whether there are other ways of achieving the objective).
Any thoughts on how I could do this?
I don't know of any current way to do it, and even the more flexible extras notation in PEP 426 doesn't quite get you there.
The closest it currently allows is "pip install myproj[-,core]". The "-" disables installing the default dependencies, but it *also* disables installing the distribution itself.
On second thoughts, I think PEP 426 does already cover this, by letting you write "pip install myproj[-:meta:,-:run:,core]". That would turn off the normal "meta_requires" and "run_requires" processing, and just install the dependencies for the "core" extra instead (which would then presumably be a subset of the normal run_requires). You'd need to specify your core dependencies in two places (once in run_requires and once for the core extra), but having setup.py as an executable format copes with that OK.
It would be possible to extend that to "pip install myproj[-,:self:,core]", where ":self:" would be a new implicit extra for installing the project itself (to go along with the currently proposed implicit extras for ":meta:", ":run:", ":build:", ":test:", and ":dev:" to indicate which dependency lists to process).
That said, I still quite like this idea of the implicit ":self:" extra. With that included, I'd drop the ability to have a standalone "-" entirely. Instead, the spelling would be "pip install myproj[-:self:]" if you just wanted the dependencies, and "pip install myproj[-:self:,-:meta:,-:run:]" would become a really complicated way of saying "don't install anything at all". Contrast that with the current PEP 426 draft where the more common "just the dependencies please" operation is spelled "pip install myproj[-,:meta:,:run:]", while the "don't install anything at all" version gets the much shorter and more cryptic "pip install myproj[-]". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12 October 2014 13:04, Nick Coghlan <ncoghlan@gmail.com> wrote:
Any thoughts on how I could do this?
I don't know of any current way to do it, and even the more flexible extras notation in PEP 426 doesn't quite get you there.
The closest it currently allows is "pip install myproj[-,core]". The "-" disables installing the default dependencies, but it *also* disables installing the distribution itself.
On second thoughts, I think PEP 426 does already cover this, by letting you write "pip install myproj[-:meta:,-:run:,core]". That would turn off the normal "meta_requires" and "run_requires" processing, and just install the dependencies for the "core" extra instead (which would then presumably be a subset of the normal run_requires).
You'd need to specify your core dependencies in two places (once in run_requires and once for the core extra), but having setup.py as an executable format copes with that OK.
Thanks, that looks good enough for my needs. I must admit to not having really investigated this part of PEP 426, so thanks for the pointer. I'll go and do some reading. All I need to do now is wait for PEP 426 to get accepted, and a version of pip with support for it to be released :-) But I don't really mind ignoring the issue for now, until that happens. It's not like the project is even fully written yet... Paul
On 12 Oct 2014 22:36, "Paul Moore" <p.f.moore@gmail.com> wrote:
On 12 October 2014 13:04, Nick Coghlan <ncoghlan@gmail.com> wrote:
Any thoughts on how I could do this?
I don't know of any current way to do it, and even the more flexible extras notation in PEP 426 doesn't quite get you there.
The closest it currently allows is "pip install myproj[-,core]". The "-" disables installing the default dependencies, but it *also* disables installing the distribution itself.
On second thoughts, I think PEP 426 does already cover this, by letting you write "pip install myproj[-:meta:,-:run:,core]". That would turn off the normal "meta_requires" and "run_requires" processing, and just install the dependencies for the "core" extra instead (which would then presumably be a subset of the normal run_requires).
You'd need to specify your core dependencies in two places (once in run_requires and once for the core extra), but having setup.py as an executable format copes with that OK.
Thanks, that looks good enough for my needs. I must admit to not having really investigated this part of PEP 426, so thanks for the pointer. I'll go and do some reading.
I don't think anyone other than me has really thought about it too much at this point - it's one of the areas in need of review and a draft reference implementation before the PEP could realistically be accepted.
All I need to do now is wait for PEP 426 to get accepted, and a version of pip with support for it to be released :-) But I don't really mind ignoring the issue for now, until that happens. It's not like the project is even fully written yet...
I think there's plenty of good upgrades on the agenda for pip 6 already, so I'll be nudging folks to start looking more closely at PEP 426 on the road to pip 7 :) Cheers, Nick.
Paul
participants (2)
-
Nick Coghlan -
Paul Moore