emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: native-comp and resetting of search paths


From: Alex Bennée
Subject: Re: native-comp and resetting of search paths
Date: Mon, 13 Jul 2020 20:51:39 +0100
User-agent: mu4e 1.5.4; emacs 28.0.50

Andrea Corallo <akrl@sdf.org> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> Hi Andrea, Jorgen,
>>
>> I just thought I'd give you a heads up on a potential clash between
>> native-comp's background compilation and elpy. In essence native-comp
>> changes the value of elpy-rpc-pythonpath from:
>>
>>   "/home/alex/.emacs.d/elpa/elpy-20200527.2021/"
>>
>> To:
>>
>>   
>> "/home/alex/.emacs.d/elpa/elpy-20200527.2021/eln-x86_64-pc-linux-gnu-93d8fa3f77c8fe62/"
>>
>> which is fine for the .elc -> .eln change but because elpy also uses
>> this to find the python server in .emacs.d/elpa/elpy-20200527.2021/elpy/
>> it gets very confused.
>>
>> What was the rationale behind this change? I can see it makes sense to
>> tweak load-path but generally I would expect variables belonging to
>> packages to remain untouched.
>>
>> Is this a recent change? it only seemed to break in the last week.
>
> Hi Alex,
>
> AFAIR nothing recently changed should cause a regression in this area.
>
> If you cold look into how elpy-rpc-pythonpath is computed I guess should
> be easy to undestand what is going on.

Hmm odd. It's a custom variable:

  (defcustom elpy-rpc-pythonpath (file-name-directory (locate-library "elpy"))
    "A directory to add to the PYTHONPATH for the RPC process.

  This should be a directory where the elpy module can be found. If
  this is nil, it's assumed elpy can be found in the standard path.
  Usually, there is no need to change this."
    :type 'directory
    :safe #'file-directory-p
    :group 'elpy)

As I've not customised it it defaults to:

  (file-name-directory (locate-library "elpy"))

Which of course now resolves to:

  
"/home/alex/.emacs.d/elpa/elpy-20200527.2021/eln-x86_64-pc-linux-gnu-93d8fa3f77c8fe62/"

So I guess this is a rare corner case because really we are using the
locate machinery as a side-effect to find the rest of the elpa install
directory.

There must be a mechanism to find the original source file because my
*helpful* buffer is able to navigate to source for all the functions
that are now native compiled so once I know what that is I can submit a
patch.

I guess the package is "wrong" for making the assumption based on the
locate-library information but it was probably a reasonable assumption
to make up to this point. I wonder if any other packages would get
broken by this changed assumption?

A quick grep of my ~/.emacs.d/elpa certainly shows a lot of packages
locate-library themselves. For example async-start has this comment:

   ;; Using `locate-library' ensure we use the right file
   ;; when the .elc have been deleted.
   (locate-library "async")

Not sure what the correct fix for those cases would be to correctly deal
with native-comp? Should we have a (locate-library-source)?

>
> Thanks
>
>   Andrea


-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]