Disable startup.jl by default?

[PallHaraldsson]

I see you added to possibility opt-in.

It has bugged my that Julia does run it by default, but I realize it's a breaking change (hypothetically, not in practice for most) to change for Julia and for your JuliaCall.

Still I'm not sure many of your users rely on the file RUN...

I don't think Python has its own startup file, and if I'm right, even either way it's surprising to many that Julia has one. Now you need to know of it, even if you don't use one, if you send your program to others.

I think it's much faster to default to it off (also for Julia and PackageCompiler.jl).

Even if you go against the grain, I think you should, since your users could easily opt into it, those that know or care about the file.

Do you know of any good uses for it, I mean when running from the Python side? Is e.g. Revise.jl an issue, wanting it? [It's been suggested to add it to Julia.]

[cjdoris]

Are there any specific bugs being caused by this?

I would argue that the user has already opted in to this behaviour by creating startup.jl in the first place, since this file does not exist by default. And since this is the default behaviour of Julia, I do not want to change the behaviour of JuliaCall without a very good reason - for instance somebody may use startup.jl to do some important initialisation which is needed regardless of whether Julia is inside Python or not.

[PallHaraldsson]

I don't have a specific problematic bug, but it's very easy to see one.

Usually you e.g. add Revise.jl there, and I don't think it helps (or hurts much, startuyp is slower for it and whatever more you add).

But if users think of Python and Julia separately (or only think they're using the former), you are adding a Python project and it just has a lot of dependencies, and even subdependencies, and one of those is a Julia package, then your package will install Julia for the user (autodownloading also a thing, when calling to rather than from Julia?), and you want reproducability.

It works, or not, depending on what is in startup.jl. It might on your machine, until shipped to a clueless enduser. And even if the user later discovers Julia as a language and everything worked and the user starts messing with the startup.jl, maybe makes a typo then a "Python projects" starts failing.

I would think of NOT using it as a safe default, and would rather want a counterexample where something doesn't work if startup.jl is NOT run. I believe there are packages possibly useful, that change stacktraces, but not essential, if those (abbreviated) stacktraces are really better should be added into Julia. Also OhMyREPL.jl is useful, not essential.

I would argue that the user has already opted in to this behaviour by creating startup.jl in the first place

Which user, the end-user or the package developer? If the file is essential, then you could distribute it with your project and run it when you first link to Julia I guess. I would postpone such extra functionality, until proven useful. It could be then opt-in to copy that file. Still yes, it would be a static copy, not a moving target, pros and cons depending on your view.

I also proposed similar for Julia: https://github.com/JuliaLang/julia/pull/51435#issuecomment-1754785645

[PallHaraldsson]

To answer my own question, there is an ENV var PYTHONSTARTUP to point to a file:

If this is the name of a readable file, the Python commands in that file are executed before the first prompt is displayed in interactive mode.

So it's NOT run by default (implied no file run), i.e. if you run a Python script (with or without calling Julia). Julia's startup.jl is run similarly, but also for scripts, at least until that is changed...

[PallHaraldsson]

FYI: At least there precedent here, VS Code disables the startup file (it seems to me, didn't look carefully), so when code moved in production from development, you CAN expect different results:

https://github.com/julia-vscode/julia-vscode/blob/275e37530cdbea05a8edccbef44515ab74d1f17d/src/extension.ts#L253

Also in Pluto the startup file is NOT run (by default): https://github.com/kirill-kondrashov/Pluto.jl/blob/b8a58fe0ae4f0d9bddbe87dec4e242cfae8b73b2/src/Configuration.jl#L238

Also https://github.com/JuliaLang/julia/issues/52532 suggestion is still open (only the duplicate of it above was closed).

[cjdoris]

It looks like that bit of the VSCode extension is just loading the language server, which is a standalone application. I don't know what VSCode does for the actual Julia process used when debugging in VSCode or running tests etc.

And for Pluto it arguably makes sense because notebooks are supposed to be totally self-contained and independent of their environment. Even then, though, I'm not totally convinced - e.g. what if some user with a weird system put some crucial bit of code into their startup.jl which is necessary for Julia to work on their system? Seems to me that if the user opts into writing a startup.jl, they should opt into it being used everywhere, and should adapt startup.jl so that it works in whatever scenario.

[PallHaraldsson]

Yes, the user should then opt into it for PythonCall.jl too. I don't worry too much about individual users, more about your package being users as infrastructure for other packages wrapping Julia. It would be best if Julia would change its default, but there's no need you need to wait for that, just document it.

[ma-sadeghi]

Here's a use case:

The user has Julia 1.9 installed for their Julia projects, and since he has a startup.jl, they've manually installed the packages required by the startup.jl.

There's a Python package the user wants to use, which uses some Julia functionality via juliacall. Upon importing juliacall (internally by the Python package) on a new virtualenv (for the new project the user has started working on), it tries to install the latest available Julia, which is 1.10.x, which doesn't have those optional dependencies installed, and hence the Python package cannot be imported.

Of course, it's easy to add those packages to 1.10, but is an unnecessary pain, especially for Python packages that solely rely on Julia as backend.

For Julia projects, I completely agree with you that they're responsible to make sure startup.jl doesn't break their script.