Two activation methods differ on results

When activating projects, I’m seeing some different results for a couple of methods I thought were supposed to be essentially the same.

This runs fine:

% julia --project=examples -e 'using MyProj'                  
julia --project=examples -e 'using MyProj'  3.72s user 1.88s system 133% cpu 4.181 total

This also runs fine:

% julia -e 'using Pkg; Pkg.activate("examples")'             
  Activating project at `~/git/MyProj.jl/examples`

This runs decidedly non-fine:

% julia -e 'using Pkg; Pkg.activate("examples"); using MyProj'
  Activating project at `~/git/MyProj.jl/examples`
ERROR: LoadError: MethodError: no method matching fit_string_in_field(::String, ::Int64; keep_escape_seq::Bool, printable_string_width::Int64)
Closest candidates are:
  fit_string_in_field(::AbstractString, ::Int64; add_continuation_char, add_space_in_continuation_char, continuation_char, crop_side, field_margin, keep_ansi, printable_string_width) got unsupported keyword argument "keep_escape_seq"
   @ StringManipulation ~/.julia/packages/StringManipulation/5Zfrz/src/crop.jl:96
Stacktrace:
  [1] kwerr(::@NamedTuple{keep_escape_seq::Bool, printable_string_width::Int64}, ::Function, ::String, ::Int64)
    @ Base ./error.jl:165
  [2] _text_print_table!(display::PrettyTables.Display, ptable::PrettyTables.ProcessedTable, table_str::Matrix{Vector{String}}, actual_columns_width::Vector{Int64}, continuation_row_line::Int64, num_lines_in_row::Vector{Int64}, num_lines_around_table::Int64, body_hlines::Vector{Int64}, body_hlines_format::NTuple{4, Char}, continuation_row_alignment::Symbol, ellipsis_line_skip::Int64, highlighters::Ref{Any}, hlines::Vector{Int64}, tf::PrettyTables.TextFormat, text_crayons::PrettyTables.TextCrayons{Crayons.Crayon, Crayons.Crayon}, vlines::Symbol)
    @ PrettyTables ~/.julia/packages/PrettyTables/oVZqx/src/backends/text/print_table.jl:216
  [3] _print_table_with_text_back_end(pinfo::PrettyTables.PrintInfo; alignment_anchor_fallback::Symbol, alignment_anchor_fallback_override::Dict{Int64, Symbol}, alignment_anchor_regex::Dict{Int64, Vector{Regex}}, autowrap::Bool, body_hlines::Vector{Int64}, body_hlines_format::Nothing, continuation_row_alignment::Symbol, crop::Symbol, crop_subheader::Bool, columns_width::Int64, display_size::Tuple{Int64, Int64}, equal_columns_width::Bool, ellipsis_line_skip::Int64, highlighters::Tuple{}, hlines::Nothing, linebreaks::Bool, maximum_columns_width::Int64, minimum_columns_width::Int64, newline_at_end::Bool, overwrite::Bool, reserved_display_lines::Int64, show_omitted_cell_summary::Bool, sortkeys::Bool, tf::PrettyTables.TextFormat, title_autowrap::Bool, title_same_width_as_table::Bool, vcrop_mode::Symbol, vlines::Nothing, border_crayon::Crayons.Crayon, header_crayon::Crayons.Crayon, omitted_cell_summary_crayon::Crayons.Crayon, row_label_crayon::Crayons.Crayon, row_label_header_crayon::Crayons.Crayon, row_number_header_crayon::Crayons.Crayon, subheader_crayon::Crayons.Crayon, text_crayon::Crayons.Crayon, title_crayon::Crayons.Crayon)
    @ PrettyTables ~/.julia/packages/PrettyTables/oVZqx/src/backends/text/text_backend.jl:371
  [4] _print_table_with_text_back_end(pinfo::PrettyTables.PrintInfo)
    @ PrettyTables ~/.julia/packages/PrettyTables/oVZqx/src/backends/text/text_backend.jl:8
  [5] _print_table(io::IO, data::Any; alignment::Symbol, backend::Val{:auto}, cell_alignment::Nothing, cell_first_line_only::Bool, compact_printing::Bool, formatters::Nothing, header::Tuple{Vector{String}}, header_alignment::Symbol, header_cell_alignment::Nothing, limit_printing::Bool, max_num_of_columns::Int64, max_num_of_rows::Int64, renderer::Symbol, row_labels::Nothing, row_label_alignment::Symbol, row_label_column_title::String, row_number_alignment::Symbol, row_number_column_title::String, show_header::Bool, show_row_number::Bool, show_subheader::Bool, title::String, title_alignment::Symbol, kwargs::@Kwargs{})
    @ PrettyTables ~/.julia/packages/PrettyTables/oVZqx/src/print.jl:1059
  [6] pretty_table(io::IO, data::Any; header::Nothing, kwargs::@Kwargs{})
...

(This goes on for quite a bit longer with more stack traces. I can give the full output if that would be helpful, but I didn’t want to paste it into this thread, is there a preferred pastebin?)

Have I missed some difference in project activation methods that would explain this? The second method is what I’m doing in a script so I want to figure out how to fix it.

Thanks.

With --project the selected project is activated at the start of the session. With Pkg.activate the global environment is activated first before switching to the selected project. This doesn’t have to be a problem but if you have a startup.jl it might load incompatible versions of some packages before you switch to your project.

Thanks @GunnarFarneback , I upgraded StringManipulation v0.3.4 ⇒ v0.4.0 in the global environment and that did the trick.

Is there a straightforward way for a project to query whether all its package requirements (including transitive requirements) are satisfied? If there were, I could add it to my script to make things obvious for some of its more casual users.