evaluating file inside let - emacs

Question

If my-variable is globally undefined, and my-file.el uses it,
;; -*- lexical-binding: t; -*-
(let((my-variable 1))
(load "/path/to/my-file.el"))
reports an error:
Debugger entered--Lisp error: (void-variable my-variable)
On the other hand,
;; -*- lexical-binding: t; -*-
(defvar my-variable 11)
(let((my-variable 1))
(load "/path/to/my-file.el"))
works using locally defined value 1.
Why do I have to use defvar?
PS: my-file.el can be a one-liner:
(1+ my-variable)

Answer 1

The file that the let is in is probably using lexical-binding, which means that for:
(let ((my-variable 1))
(load "/path/to/my-file.el"))
There is nothing in the lexical scope of my-variable which uses it.
If you byte-compiled the file, it would tell you:
Warning: Unused lexical variable ‘my-variable’
Adding the defvar marks it as a dynamic scope variable, in which case the code evaluated while my-file.el is being loaded will also see the let-bound value.
Note that (defvar my-variable) with no value is also sufficient to do that, and is what you should use if this isn't where the variable is supposed to be defined.

Answer 2

See Using Lexical Binding:
Lexical binding is also enabled in Lisp Interaction and IELM mode, used in the scratch and ielm buffers, and also when evaluating expressions via M-: (eval-expression) and when processing the --eval command-line options of Emacs (see Action Arguments in The GNU Emacs Manual) and emacsclient (see emacsclient Options in The GNU Emacs Manual).
So, if you evaluate the let in the *scratch* buffer, it uses lexical binding, which means the value of the variable is only bound to the lexical context, i.e. it isn't preserved when loading a different file.
Another possibility is you run it from an .el file with lexical binding turned on. If you turn it off, it should work the way you expected. Use the buffer local variable lexical-binding to enable or disable it.

Answer 3

[Not an answer but I did not want to edit the OP's question willy-nilly with what I see (and it's too long for a comment). I just provide a description of how I reproduce the problem since #choroba seems to get different results]
I have this in /tmp/my-file.el:
(if (= my-variable 1) (message "Yes") (message "N
I start emacs with emacs -Q and evaluate the following in the *scratch* buffer (sneaking in the version info):
(emacs-version '(4))
GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.25, cairo version 1.16.0)
of 2021-03-07nil
(let ((my-variable 1))
(message (format "%d" my-variable))
(load "/tmp/foo.el"))
and I get the following backtrace:
Debugger entered--Lisp error: (void-variable my-variable)
(= my-variable 1)
(if (= my-variable 1) (message "Yes") (message "No"))
eval-buffer(#<buffer *load*> nil "/tmp/foo.el" nil t) ; Reading at buffer position 54
load-with-code-conversion("/tmp/foo.el" "/tmp/foo.el" nil nil)
load("/tmp/foo.el")
(let ((my-variable 1)) (message (format "%d" my-variable)) (load "/tmp/foo.el"))
(progn (let ((my-variable 1)) (message (format "%d" my-variable)) (load "/tmp/foo.el")))
eval((progn (let ((my-variable 1)) (message (format "%d" my-variable)) (load "/tmp/foo.el"))) t)
elisp--eval-last-sexp(t)
eval-last-sexp(t)
eval-print-last-sexp(nil)
funcall-interactively(eval-print-last-sexp nil)
call-interactively(eval-print-last-sexp nil nil)
command-execute(eval-print-last-sexp)
I get exactly the same result with the emacs that is packaged in my distro (Fedora 33): GNU Emacs 27.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.22, cairo version 1.16.0) of 2020-08-20.