Runtime package dependencies and compilation order

Runtime package dependencies and compilation order

[Boris]

Hello,

Recently I've faced following problem. I have a package A that might depend
on package B or (disjunction) package C. But dependency list is not known
upwards, because the list itself depends on user settings. So I don't
specify B and C in package requires section of package A. All packages are
on MELPA and installed via package.el. The problem comes when someone wants
to use the part of package A that depends on package B - if package A is
byte compiled before B, then some functionality doesn't work and you have
to manually recompile A. So the solution might be pretty simple - ask user
to install package A after package B. But in some setups there is no way (I
mean, good way) of enforcing specific order of installation. And in any
case I feel like asking such thing from users is not the right thing.

From my understanding specifying package B as dependency solves such
issues, as package manager installs B before A. So the only solution I see
in such situation is to create package A-base, A-B (B-related functionality
that has two packages as dependency - A-base and B) and A-C (similar to
A-B).

So I would like to ask if there's any other solution for the described
problem?

I hope that this is the right place to ask such questions, and sorry for
such an abstract description.

Best regards,
Boris
-- 
Best regards,
Boris @ d12frosted

Re: Runtime package dependencies and compilation order

[Emanuel Berg]

Boris <d12frosted@gmail.com> writes:

> Recently I've faced following problem. I have
> a package A that might depend on package B or
> (disjunction) package C. But dependency list
> is not known upwards, because the list itself
> depends on user settings. So I don't specify
> B and C in package requires section of
> package A.

"package B or (disjunction) package C" - does
this mean you can't `require' both?
Why not? Collisions?

If so, the idea of the "require list as an
option" strikes me as odd.

Did you see it all over the MELPA world? Scary.

Better: require both B and C.

If you don't want to change the code all over
the place in A (which also is possible), there
are many workarounds that shouldn't be too
slow, for example can you create a "function
pool" and a bunch of variables in A to hold
functions. When the user switches from B to
C mode, or the other way around, the function
pool reassigns the functions in effect in A.

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 42 Blogomatic articles -                   

Re: Runtime package dependencies and compilation order

[Michael Heerdegen]

Boris <d12frosted@gmail.com> writes:

> Recently I've faced following problem. I have a package A that might
> depend on package B or (disjunction) package C.

Is this an exclusive "or"?  If not, why not just depend on B _and_ C?

In the other case I cannot suggest anything better than what you already
did.  Since AFACT, Emacs package management doesn't (yet?) allow
dependencies of type "X or Y" (unlike some OS).  But I wonder...

> The problem comes when someone wants to use the part of package A that
> depends on package B - if package A is byte compiled before B, then some
> functionality doesn't work and you have to manually recompile A.

...is really the compilation order a problem, or the fact that A had
been compiled without B being _loaded_?  Doesn't make much a difference
from the end user's view, though.


Regards,

Michael.

Re: Runtime package dependencies and compilation order

[Boris]

Hey Michael,

Thanks for your reply.

> Is this an exclusive "or"?  If not, why not just depend on B _and_ C?

It's not exclusive, it's disjunction. I don't want to depend on both of
them because they are huge. And some people would not like having orphan
package to be installed as dependency.

> ...is really the compilation order a problem, or the fact that A had
> been compiled without B being _loaded_?  Doesn't make much a difference
> from the end user's view, though.

Good question. And I am not sure. I'll look into it. Just out of curiosity.

> In the other case I cannot suggest anything better than what you already
> did.

Alright, then I'll just implement my solution. In any case, I like it. Just
wanted to hear others opinion.

Thanks again and best regards,
Boris

On Tue, May 31, 2016 at 5:47 PM Michael Heerdegen <michael_heerdegen@web.de>
wrote:

> Boris <d12frosted@gmail.com> writes:
>
> > Recently I've faced following problem. I have a package A that might
> > depend on package B or (disjunction) package C.
>
> Is this an exclusive "or"?  If not, why not just depend on B _and_ C?
>
> In the other case I cannot suggest anything better than what you already
> did.  Since AFACT, Emacs package management doesn't (yet?) allow
> dependencies of type "X or Y" (unlike some OS).  But I wonder...
>
> > The problem comes when someone wants to use the part of package A that
> > depends on package B - if package A is byte compiled before B, then some
> > functionality doesn't work and you have to manually recompile A.
>
> ...is really the compilation order a problem, or the fact that A had
> been compiled without B being _loaded_?  Doesn't make much a difference
> from the end user's view, though.
>
>
> Regards,
>
> Michael.
>

Re: Runtime package dependencies and compilation order

[Stefan Monnier]

> From my understanding specifying package B as dependency solves such
> issues, as package manager installs B before A. So the only solution I see
> in such situation is to create package A-base, A-B (B-related functionality
> that has two packages as dependency - A-base and B) and A-C (similar to
> A-B).

Without knowing more of the details (and taking as a given that you're
not interested in extending the ELPA infrastructure to support
disjunction in dependencies), I think your solution is indeed about as
good as it gets.

There is a hackish alternative, where you provide an B-C (meta) package,
with two *versions* (one that depends on B and the other that depends on
C), but ELPA generally presumes that there's only one interesting
version (the latest), so it'll probably be cumbersome to use.

But there's no reason to take ELPA as something that's cast in stone.
So I recommend you file a bug-report asking for better support for your
use-case.


        Stefan

Re: Runtime package dependencies and compilation order

[Emanuel Berg]

Boris <d12frosted@gmail.com> writes:

>> Is this an exclusive "or"? If not, why not
>> just depend on B _and_ C?
>
> It's not exclusive, it's disjunction. I don't
> want to depend on both of them because they
> are huge. And some people would not like
> having orphan package to be installed
> as dependency.

C'mon, how big can they be?

Also, if you put a switch into A to toggle
between B and C mode, it doesn't count as an
"orphan package" just because it isn't selected
by default!

Even in vanilla Emacs, there are tons of stuff
I never use and never will use, and that never
bothered me at all.

Stuff that are unused are only annoying if it
is visible!

-- 
underground experts united .... http://user.it.uu.se/~embe8573
Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic
                   - so far: 42 Blogomatic articles -