text:
Checking file with rule W605 cause panic

ruff 0.5.0+130 (7c8112614 2024-07-02)
ruff *.py --select W605 --no-cache  --preview --output-format concise --isolated

file content(at the bottom should be attached raw, not formatted file - github removes some non-printable characters, so copying from here may not work):
import typing as t
from Éutils import Namespace
if t.TYPE_CHECKING:
    import typing_extensions as te
NEWLINE_SEQUENCE: "te.Literal['\\n', '\\r\\n', '\\r']" = "\n"

error
All checks passed!

error: Panicked while linting /home/rafal/test/tmp_folder/13825409523151480423.py: This indicates a bug in Ruff. If you could open an issue at:

    https://github.com/astral-sh/ruff/issues/new?title=%5BLinter%20panic%5D

...with the relevant file contents, the `pyproject.toml` settings, and the following stack trace, we'd be very appreciative!

panicked at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_source_file/src/locator.rs:463:23:
byte index 25 is not a char boundary; it is inside 'É' (bytes 24..26) of `import typing as t
from Éutils import Namespace
if t.TYPE_CHECKING:
    import typing_extensions as te
NEWLINE_SEQUENCE: "te.Literal['\\n', '\\r\\n', '\\r']" = "\n"`
Backtrace:    0: ruff::panic::catch_unwind::{{closure}}
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/panic.rs:31:25
   1: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/alloc/src/boxed.rs:2036:9
   2: std::panicking::rust_panic_with_hook
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:799:13
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:664:13
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/sys_common/backtrace.rs:171:18
   5: rust_begin_unwind
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:652:5
   6: core::panicking::panic_fmt
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/panicking.rs:72:14
   7: core::str::slice_error_fail_rt
   8: core::str::slice_error_fail
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/str/mod.rs:89:5
   9: core::str::traits::<impl core::slice::index::SliceIndex<str> for core::ops::range::Range<usize>>::index
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/str/traits.rs:244:21
  10: core::str::traits::<impl core::ops::index::Index<I> for str>::index
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/str/traits.rs:62:15
  11: ruff_text_size::range::<impl core::ops::index::Index<ruff_text_size::range::TextRange> for str>::index
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_text_size/src/range.rs:430:14
  12: ruff_source_file::locator::Locator::slice
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_source_file/src/locator.rs:463:23
  13: ruff_linter::rules::pycodestyle::rules::invalid_escape_sequence::check
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_linter/src/rules/pycodestyle/rules/invalid_escape_sequence.rs:133:18
  14: ruff_linter::rules::pycodestyle::rules::invalid_escape_sequence::invalid_escape_sequence
  15: <ruff_linter::checkers::ast::Checker as ruff_python_ast::visitor::Visitor>::visit_expr
  16: ruff_python_ast::visitor::walk_expr
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_python_ast/src/visitor.rs:543:17
  17: <ruff_linter::checkers::ast::Checker as ruff_python_ast::visitor::Visitor>::visit_expr
  18: <ruff_linter::checkers::ast::Checker as ruff_python_ast::visitor::Visitor>::visit_expr
  19: ruff_linter::checkers::ast::Checker::visit_deferred_string_type_definitions
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_linter/src/checkers/ast/mod.rs:2203:21
  20: ruff_linter::checkers::ast::Checker::visit_deferred
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_linter/src/checkers/ast/mod.rs:2286:13
  21: ruff_linter::checkers::ast::check_ast
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_linter/src/checkers/ast/mod.rs:2414:5
  22: ruff_linter::linter::check_path
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_linter/src/linter.rs:146:36
  23: ruff_linter::linter::lint_only
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff_linter/src/linter.rs:409:23
  24: ruff::diagnostics::lint_path
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/diagnostics.rs:321:22
  25: ruff::commands::check::lint_path::{{closure}}
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/commands/check.rs:192:9
  26: std::panicking::try::do_call
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:559:40
  27: std::panicking::try
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:523:19
  28: std::panic::catch_unwind
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panic.rs:149:14
  29: ruff::panic::catch_unwind
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/panic.rs:40:18
  30: ruff::commands::check::lint_path
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/commands/check.rs:191:18
  31: ruff::commands::check::check::{{closure}}
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/commands/check.rs:93:17
  32: <rayon::iter::filter_map::FilterMapFolder<C,P> as rayon::iter::plumbing::Folder<T>>::consume
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/filter_map.rs:123:36
  33: rayon::iter::plumbing::Folder::consume_iter
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/plumbing/mod.rs:178:20
  34: rayon::iter::plumbing::Producer::fold_with
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/plumbing/mod.rs:109:9
  35: rayon::iter::plumbing::bridge_producer_consumer::helper
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/plumbing/mod.rs:437:13
  36: rayon::iter::plumbing::bridge_producer_consumer
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/plumbing/mod.rs:396:12
  37: <rayon::iter::plumbing::bridge::Callback<C> as rayon::iter::plumbing::ProducerCallback<I>>::callback
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/plumbing/mod.rs:372:13
  38: <rayon::slice::Iter<T> as rayon::iter::IndexedParallelIterator>::with_producer
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/slice/mod.rs:826:9
  39: rayon::iter::plumbing::bridge
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/plumbing/mod.rs:356:12
  40: <rayon::slice::Iter<T> as rayon::iter::ParallelIterator>::drive_unindexed
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/slice/mod.rs:802:9
  41: <rayon::iter::filter_map::FilterMap<I,P> as rayon::iter::ParallelIterator>::drive_unindexed
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/filter_map.rs:46:9
  42: <rayon::iter::fold::Fold<I,ID,F> as rayon::iter::ParallelIterator>::drive_unindexed
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/fold.rs:59:9
  43: rayon::iter::reduce::reduce
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/reduce.rs:15:5
  44: rayon::iter::ParallelIterator::reduce
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rayon-1.10.0/src/iter/mod.rs:998:9
  45: ruff::commands::check::check
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/commands/check.rs:163:10
  46: ruff::check
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/lib.rs:413:13
  47: ruff::run
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/lib.rs:186:33
  48: ruff::main
             at /home/runner/work/Automated-Fuzzer/Automated-Fuzzer/ruff/crates/ruff/src/main.rs:85:11
  49: core::ops::function::FnOnce::call_once
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ops/function.rs:250:5
  50: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/sys_common/backtrace.rs:155:18
  51: std::rt::lang_start::{{closure}}
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:159:18
  52: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ops/function.rs:284:13
  53: std::panicking::try::do_call
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:559:40
  54: std::panicking::try
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:523:19
  55: std::panic::catch_unwind
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panic.rs:149:14
  56: std::rt::lang_start_internal::{{closure}}
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:141:48
  57: std::panicking::try::do_call
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:559:40
  58: std::panicking::try
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:523:19
  59: std::panic::catch_unwind
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panic.rs:149:14
  60: std::rt::lang_start_internal
             at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/rt.rs:141:20
  61: main
  62: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  63: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:360:3
  64: _start

Ruff build, that was used to reproduce problem(compiled on Ubuntu 22.04 with relase mode + debug symbols + debug assertions + overflow checks) - https://github.com/qarmin/Automated-Fuzzer/releases/download/Nightly/ruff.7z
python_compressed.zip

Huh, the position where the rule is panicking would suggest that the range on a literal is incorrect.

Yeah, I can confirm that this is related to https://github.com/astral-sh/ruff/issues/10586. You can see that the range of the inner strings are relative to the outer string:
String(
    ExprStringLiteral {
        range: 122..158,
        value: StringLiteralValue {
            inner: Single(
                StringLiteral {
                    range: 11..15,
                    value: "\n",
                    flags: StringLiteralFlags {
                        quote_style: Single,
                        prefix: Empty,
                        triple_quoted: false,
                    },
                },
            ),
        },
    },
)
String(
    ExprStringLiteral {
        range: 122..158,
        value: StringLiteralValue {
            inner: Single(
                StringLiteral {
                    range: 17..23,
                    value: "\r\n",
                    flags: StringLiteralFlags {
                        quote_style: Single,
                        prefix: Empty,
                        triple_quoted: false,
                    },
                },
            ),
        },
    },
)
String(
    ExprStringLiteral {
        range: 122..158,
        value: StringLiteralValue {
            inner: Single(
                StringLiteral {
                    range: 25..29,
                    value: "\r",
                    flags: StringLiteralFlags {
                        quote_style: Single,
                        prefix: Empty,
                        triple_quoted: false,
                    },
                },
            ),
        },
    },
)

I'll close this in favor of #10586

authors: MichaReiser dhruvmanila qarmin

repo: astral-sh/ruff


text:
(🎁) preserve node line of noqa comments when formatting

dict(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=1)  # noqa: C408

after format (fail)
dict(
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=1
)  # noqa: C408

ruff is doing the checking of this noqa, ruff is also the one doing the formating, so it would seem logical that ruff use the check information to keep the noqa on the right line
dict(  # noqa: C408
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=1
)

related #8232

I understand why this is desired, but it has quite far-reaching implications, and it would significantly slow down formatting because formatting would require running the linter, a trade-off that I think isn't worth the occasional move of a noqa comment.
Long-term, this does not just apply to running the linter but also type-checking and there are suppression comments that ruff doesn't even understand. So the problem doesn't go away, it might just happen less often (which would already be nice).
To me the most likely solution is redesigning suppression comments so that it is known what target they suppress by being more explicit about where they can be placed. E.g. only allow own-line suppression comments, maybe even on a statement level.

99% of the time I want to both format and check, currently it's two separate steps, and I would presume that would make it take longer
Personally I would love to trade speed for more correctness, but know not everyone thinks the same

I have the same problem with with mypy's type: ignore comments.
For example, the following line:
    def parse_document(self, document: DocumentInfo, stream: BytesIO, effective: datetime.date, span: Span) -> None:  # type: ignore[override]
        ...

Gets reformatted as:
    def parse_document(
        self, document: DocumentInfo, stream: BytesIO, effective: datetime.date, span: Span
    ) -> None:  # type: ignore[override]
        ...

Which makes mypy unable to detect the ignore comment, as it has been moved to the incorrect place.
Black prevents splitting lines that contain type: ignore comments. Maybe this could be added as an option to Ruff formatter?

Another example I've run into:
Here's my one_line.py file before ruff:
from implementations.endpoints.name_of_some_module import very_very_long_name_of_some_function # noqa: F401

$ ruff check one_line.py
All checks passed!
$ ruff format one_line.py
1 file reformatted
$ ruff check one_line.py
... cut details ...
Found 1 error.
[*] 1 fixable with the `--fix` option.

Reformatted file:
from implementations.endpoints.name_of_some_module import (
    very_very_long_name_of_some_function,
) # noqa: F401

Workaround:
# fmt: off
from implementations.endpoints.name_of_some_module import very_very_long_name_of_some_function # noqa: F401
# fmt: on

@PamelaM that looks very similar to #12179

source: gharchive/issue

authors: KotlinIsland MichaReiser PamelaM filips123

license: MIT

license_type: permissive

license_source: github-api


text:
Remove the early days ruff_python_formatter CLI

Summary
This PR deletes the ruff_python_formatter/src/main.rs that we used for testing in the very early days.
This reduces the number of build targets by one.
Test Plan
cargo build

@konstin still uses it. Let's keep it for now (even if it means having a dependency on clap :( )

source: gharchive/pull-request


text:
Fix type subscript on older python versions

Summary
Python versions before Python 3.9 don't have subscriptable containers like list, which is being used in the annotation of get_last_three_path_parts here.  I believe Ruff supports Python 3.7 and Python 3.8?  In that case this needs to either use the container from the typing module, or use deferred annotations with from __future__ import annotations like I'm proposing here
Introduced by https://github.com/astral-sh/ruff/commit/60a2dc53e7b4407c3c0c14093fd8542879997ca8
Test Plan
Currently the code path in find_ruff_bin that defines get_last_three_path_parts doesn't work on Python 3.8 or 3.9, it throws this:
>>> ruff.__main__.find_ruff_bin()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/aaron/miniconda3/envs/symforce/lib/python3.8/site-packages/ruff/__main__.py", line 77, in find_ruff_bin
    raise FileNotFoundError(scripts_path)
FileNotFoundError: /home/aaron/miniconda3/envs/symforce/bin/ruff

With this change it does work

Thanks for PRing this fix
@charliermarsh would you mind taking a look at this PR. I don't think I'm the right person :)

I guess that's actually fine. Even I understand why this is needed with a summary as good as this one. Thank you

Yeah this looks correct to me.

authors: MichaReiser aaron-skydio charliermarsh


text:
uv pip sync removes pip when syncing dependencies from a requirements.txt without pip

uv 0.2.5 (47db418ba 2024-05-28)
Is this the expected behavior? I'm concerned that UV might not handle some exceptional cases yet. Therefore, I always add the --seed flag when initializing a virtual environment with UV.  If this is indeed the expected behavior, I suppose I'll need to add pip to the requirements.in file, even though including pip in there seems a bit strange.
❯ uv pip sync .\uv_requirements.txt --verbose
DEBUG Searching for Python interpreter in virtual environments
DEBUG Found CPython 3.10.11 at `C:\Users\user\Documents\source\temp\.venv\Scripts\python.exe` (active virtual environment)
DEBUG Using Python 3.10.11 environment at .venv\Scripts\python.exe
DEBUG Acquired lock for `.venv`
DEBUG Using registry request timeout of 30s
DEBUG Solving with target Python version 3.10.11
DEBUG Adding direct dependency: certifi==2024.6.2
DEBUG Adding direct dependency: charset-normalizer==3.3.2
DEBUG Adding direct dependency: idna==3.7
DEBUG Adding direct dependency: requests==2.32.3
DEBUG Adding direct dependency: urllib3==2.2.1
DEBUG Found fresh response for: https://pypi.org/simple/certifi/
DEBUG Found fresh response for: https://pypi.org/simple/idna/
DEBUG Searching for a compatible version of certifi (==2024.6.2)
DEBUG Found fresh response for: https://pypi.org/simple/requests/
DEBUG Found installed version of certifi==2024.6.2 that satisfies preference in ==2024.6.2
DEBUG Selecting: certifi==2024.6.2 (installed)
DEBUG Found fresh response for: https://pypi.org/simple/urllib3/
DEBUG Found fresh response for: https://pypi.org/simple/charset-normalizer/
DEBUG Searching for a compatible version of charset-normalizer (==3.3.2)
DEBUG Found installed version of charset-normalizer==3.3.2 that satisfies preference in ==3.3.2
DEBUG Selecting: charset-normalizer==3.3.2 (installed)
DEBUG Searching for a compatible version of idna (==3.7)
DEBUG Found installed version of idna==3.7 that satisfies preference in ==3.7
DEBUG Selecting: idna==3.7 (installed)
DEBUG Searching for a compatible version of requests (==2.32.3)
DEBUG Found installed version of requests==2.32.3 that satisfies preference in ==2.32.3
DEBUG Selecting: requests==2.32.3 (installed)
DEBUG Searching for a compatible version of urllib3 (==2.2.1)
DEBUG Found installed version of urllib3==2.2.1 that satisfies preference in ==2.2.1
DEBUG Selecting: urllib3==2.2.1 (installed)
DEBUG Tried 6 versions: certifi 1, charset-normalizer 1, idna 1, requests 1, root 1, urllib3 1
Resolved 5 packages in 5ms
DEBUG Requirement already installed: certifi==2024.6.2
DEBUG Requirement already installed: charset-normalizer==3.3.2
DEBUG Requirement already installed: idna==3.7
DEBUG Requirement already installed: requests==2.32.3
DEBUG Requirement already installed: urllib3==2.2.1
DEBUG Unnecessary package: build==1.2.1
DEBUG Unnecessary package: click==8.1.7
DEBUG Unnecessary package: colorama==0.4.6
DEBUG Unnecessary package: packaging==24.0
DEBUG Unnecessary package: pip==24.0
DEBUG Unnecessary package: pip-tools==7.4.1
DEBUG Unnecessary package: pyproject-hooks==1.1.0
DEBUG Unnecessary package: setuptools==70.0.0
DEBUG Unnecessary package: tomli==2.0.1
DEBUG Unnecessary package: wheel==0.43.0
DEBUG Uninstalled build (34 files, 5 directories)
DEBUG Uninstalled click (39 files, 3 directories)
DEBUG Uninstalled colorama (31 files, 6 directories)
DEBUG Uninstalled packaging (36 files, 3 directories)
DEBUG Uninstalled pip (529 files, 106 directories)
DEBUG Uninstalled pip-tools (55 files, 9 directories)
DEBUG Uninstalled pyproject-hooks (13 files, 5 directories)
DEBUG Uninstalled setuptools (494 files, 63 directories)
DEBUG Uninstalled tomli (14 files, 3 directories)
DEBUG Uninstalled wheel (62 files, 9 directories)
Uninstalled 10 packages in 176ms
 - build==1.2.1
 - click==8.1.7
 - colorama==0.4.6
 - packaging==24.0
 - pip==24.0
 - pip-tools==7.4.1
 - pyproject-hooks==1.1.0
 - setuptools==70.0.0
 - tomli==2.0.1
 - wheel==0.43.0

uv_requirements.txt

Yes, uv pip sync removes any dependencies that aren't in the requirements file. Are you looking for uv pip install?

Yes, uv pip sync removes any dependencies that aren't in the requirements file. Are you looking for uv pip install?

I know uv pip install , but I recently wanted to try using uv pip compile and uv pip sync to manage my environment dependencies. However, I was surprised to find that uv pip sync removes pip if it is not specified in the dependency file. This is different from pip-tools's pip-sync, which does not remove pip.
Therefore, if I need to keep pip, setuptools, and wheel in my environment, I need to explicitly include them in my requirements.in file.

I think you should mark them as necessary dependencies then, yeah.

I think you should mark them as necessary dependencies then, yeah.

Since it is expected behavior, I will write them(pip, setuptools, and wheel) to requirements.in.

We actually do preserve them, I think, if you create the virtualenv with a tool other than uv, with the assumption being that you need the seed packages in that case, but don't if you're using uv.

We actually do preserve them, I think, if you create the virtualenv with a tool other than uv, with the assumption being that I

Just tried other ways of creating a virtual environment, and seed packages are indeed retained.
When creating a virtual environment with UV, seed packages can be optionally installed. This suggests that there is a possibility of using UV but requiring seed packages.

authors: FishAlchemist charliermarsh

repo: astral-sh/uv


text:
Add DataprocCreateClusterOperatorAsync

Issue: https://github.com/astronomer/astronomer-providers/issues/424
Add Support for DataprocCreateClusterOperatorAsync.

Add hook/operator/trigger
Unit Test
Example DAG for integration test

Tests are failing

yes, I feel because of Circle CI cache.

repo: astronomer/astronomer-providers


text:
Add regression test for rtd.io

Add test to suite ensuring that the substring "readthedocs.org" never appears in any repo file. There is already a self-reading test module whose pattern can be matched: halotools/tests/test_amurrica.py
CC @bsipocz

Wow, you take testing very seriously :smile:
However this is far from being critical, a snipset from the RTD post about the change (io vs org domain), so even if the org is used it should work:
Projects will automatically be redirected, and this redirect will remain in place for the foreseeable future. Still, you should plan on updating links to your documentation after the new domain goes live.

On the other hand what would be quite useful is to have a script that checks whether all the external links in a repo work. Then optionally this can be build into the remote-data testing option.

yeah, ok, this is overkill. I guess I've just got testing on the brain lately.
I started fooling around with the auto-detection feature you described and made some headway. This is sort of fun. I'll tag you if I get anywhere useful/robust with it.

authors: aphearin bsipocz

repo: astropy/halotools


text:
Merge spectral regions

Spectral-regions have been defined in specutils:
https://github.com/astropy/specutils/pull/289
They should be included in regions eventually, especially since CRTF now supports spectral region serialization.

@keflavich - What does including spectral regions here mean?
Is it just adding something to the I/O and specutils becomes an optional dependency?
Or do you mean changes to the data classes and possibly backwards-incompat breaks?

It means adding things; I don't see any reason there should be any backward-incompatible breaks.
I'm uncertain whether specutils would become a dependency.

authors: cdeil keflavich

repo: astropy/regions


text:
🛑 sai-website is down

In b124bec, sai-website (https://saicambodianartist.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: sai-website is back up in d7f4d86.

repo: asurraa/status


text:
Error when compare

Hi,
i tried csvdiff but i have an error comparing files :
csvdiff failed: error processing base file: record on line 7: wrong number of fields
on line 7, i have the same number of fields but in a field there seem to be a tabulation...
The csv is generated by a program and it is separated by ; so why does it complain about the number of fields ? because of the tab in the field ?
Thanks in advance

Actually right now it does not support non-comma separators. Only comma is treated as the delimiter. Does supporting ";" as a separator help fix your issue? I can work on a fix to support other characters for delimiting.

Closing this issue as non-comma separators are allowed now.

repo: aswinkarthik/csvdiff


text:
Structs imported with use {Something as Another} still use the original name in the GraphQL schema

Expected Behavior
I expect that importing as another name will use the new name, not the original. I'm sure this is more complex but my use case is that I have a generated struct from a gRPC backend I'm doing the #[Object] impl on, but the name isn't suitable to be exposed to the client. My only option so far seems to be recreating the struct which seems tedious and unnecessary.
Barring that, it'd be nice to have a #[graphql(name = "blah")] for an impl, but that seems to not work either currently.
Actual Behavior
The struct shows up in the schema as the original name regardless of what it's imported as, or allow an override.
Steps to Reproduce the Problem

import something as another name
Use in the schema
Observe the name in the playground is the original name, not the imported name.

Specifications

Version: 2.9
Platform: Mac
Subsystem:

Attribute macros must pass parameters in the following way.
#[Object(name = "blah")]

Ah I see, thank you!

repo: async-graphql/async-graphql


text:
Add document for Input Validator with Extensions

Just an update example for InputValueValidator with Extensions in async doc.

Thanks!😃


text:
parser: move code generation into a test

Move the pest parser code generation step into a test. Makes it so that downstream users don't have to spend the time compiling some of the dependencies (in this case, pest_meta and its sha-1 dependency).
Inspired by https://github.com/steveklabnik/semver-parser/pull/50. It's not as big an improvement here because we still depend on serde's Serialize and Deserialize macros, but seems like a nice improvement anyway.

LGTM 🙂

@djc An absolute path will be generated here, do you know how to solve it? 😁
https://github.com/async-graphql/async-graphql/blob/ad05baf79aea55a0827291abf55af5ce7cc8d386/parser/src/parse/generated.rs#L8

Ah, so I guess the pest derive macro expands the relative path to the grammar to an absolute path? I guess you can just patch up the generated code in the code generation test, by generating the same absolute path and replacing it with a relative path?
Also, what's the reason for merging this into the v4 branch? It seems semver-compatible, so could just go in v3, right?


text:
Make it easier to create templates and glee projects

Reason/Context
We have had talks before about making it easier to create new generator templates through something like npx create-asyncapi-template. However, I think that our CLI could fulfill that role to offer a better user experience for developers, to easily bootstrap new templates or glee projects.
Notice: Glee already use npx for setup
What do you think, does it fit the CLI use-case?

imho yes, AsyncAPI CLI should be a single place where we integrate all AsyncAPI tools to make work from the terminal a pleasure. So folks install just one tool to use all the others. One 💍 to rule them all 🤓
it is just a matter of coming up with proper command names and good DX

Hey, this sounds amazing!! 🤩
Would like to work on this.

Would bootstrap make sense? 🤔
asyncapi bootstrap glee --output ./output-dir
asyncapi bootstrap glee mqtt --output ./output-dir

asyncapi bootstrap template --output ./output-dir
//Incase you want to copy an existing template
asyncapi bootstrap template @asyncapi/java-cloud-stream --output ./output-dir

I think scaffold is more accurate technical word that would explain what is done, not sure bootstrap is correct 🤔
can you provide some more explanation of what each command would actually generate?

Yes @derberg , scaffold sounds less confusing than bootstrap.
So I was thinking to start it with, something like support of Async API for NextJS API Directory.
Objective:
The user can create NextJS Serverside Asynchronous APIs from the AsyncAPI spec file.
Assuming, AsyncAPI and NextJS are installed globally.
Steps

User should be able to run ->
asyncapi scaffold nextjs --output <NextJS_API_Directory>

This builds a directory with particular endpoints as separate filenames (That's how NextJS function), and a NextJS friendly code.
The --typescript flag will help to choose the language.

Your suggestions: @jonaslagoni

What about new? We already have it and would be just a matter of extending it:
asyncapi new --> New AsyncAPI file, as it is now.
asyncapi new file --> Same as above.
asyncapi new project --> New Glee project
asyncapi new glee --> New Glee project
asyncapi new generator --> New Generator template (or generator if we end up calling them like this)
asyncapi new generator --clone @asyncapi/java-cloud-stream --> In case you want to clone an existing one

new sounds more relevant to the scope ✌ .
We can add a code generator  for different frameworks too
For example:->  NextJS, which requires customization to NextJS Formatted Code and Directories for APIs.

new sounds good to me, simple.

Same here 🎉

Hey guys! 👋 @jonaslagoni @derberg @imabp @fmvilas
I've been having a look and investigating a bit on this issue and I'd like to start working on it to keep on contributing to the CLI repo. If no objections from your side, I'll take it up and get back to you with a proposal as soon as I have some working code 💪 Cheers!

No objections from my side 👍 🚀

Hey guys! 👋 @jonaslagoni @derberg @imabp @fmvilas I've been having a look and investigating a bit on this issue and I'd like to start working on it to keep on contributing to the CLI repo. If no objections from your side, I'll take it up and get back to you with a proposal as soon as I have some working code 💪 Cheers!

Awesome @peter-rr!
Not sure how you want to do it, but as a suggestion, don't try to jam everything into one PR :) Start small with one of the commands like asyncapi new glee, and make a PR and gradually add features 🙂

I'm happy to be a mentor for this issue in the Mentorship program.

@fmvilas As I said I'd be happy to contribute on this issue 💪 So I'd like to do it as part of the Mentorship program if selected :) Cheers!!

Still relevant, don't close it :)

Hey folks! I'm about to start working in this issue and I think it would be more convenient if we split it into two different issues:

Create glee projects
Create templates

My idea is to focus on creation of glee projects for now, so the the other issue about creation of templates would be available to be picked by anybody else. @Souvikns I know you were interested recently in working on this issue, so I was thinking maybe you'd like to pick the second issue I've proposed (Create templates). If that's the case, feel free to create a new issue for that purpose 😉 What do you think, guys?

It's always a good idea to split things in smaller chunks 👍

By the way, in order to implement the creation of glee projects, I was considering the option of using the create-glee-app command inside the code, but not sure whether that's something out of the scope for this issue or then the main goal should be to bootstrap the glee project manually without making use of that command at all 🤔
Besides, I don't know what is planned for this repository in the future, so I doubt if I should rely on it or it might be better to avoid using it. Any ideas or suggestions on this?

Please completely avoid using create-glee-app. It will be deprecated in favor of this command.

Yeah @peter-rr I would love to help. What would be a good idea

to use examples in glee as templates so that CLI can pull them during build something we are currently doing https://github.com/asyncapi/cli/blob/master/scripts/fetch-asyncapi-example.js
Or have a separate templates folder in glee for specific templates.

I'm not really sure about what should be the strategy in terms of templates organization 🤔 Maybe @fmvilas or @jonaslagoni have some suggestions about it 💭

As for Glee, I think it makes sense to be able to fetch a Glee example somehow. As we're doing right now in create-glee-app with the -e, --example option: https://github.com/asyncapi/create-glee-app#options. Take into account that creating a Glee project is not just a matter of picking an AsyncAPI to start with but also some example code in the functions.

So you dont just want the bare configuration for a Glee project to be setup alongside the AsyncAPI document, you actually want it to implement business logic @fmvilas? 🧐

No no, just be able to "clone" an example from the examples folder in Glee or a [Git|Gitub] URL. Just what we have right now with create-glee-app. Also a cool feature of create-next-app.

authors: Souvikns derberg fmvilas imabp jonaslagoni peter-rr

repo: asyncapi/cli


text:
docs: improve readme

Description
This PR fixes the blackbox badge and includes the CLI usage example

Pull Request Test Coverage Report for Build 4018224256

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 92.409%

Totals

Change from base Build 4016368865:
0.0%

Covered Lines:
4734

Relevant Lines:
4993

💛  - Coveralls

authors: coveralls jonaslagoni

repo: asyncapi/modelina


text:
chore: fix-1392 added info for java specific options

this PR tries to add info for the java specific options as mentioned in the issue #1392

Pull Request Test Coverage Report for Build 5282948698

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 92.192%

Totals

Change from base Build 5268197404:
0.0%

Covered Lines:
5259

Relevant Lines:
5562

💛  - Coveralls

@jonaslagoni sorry for the delay, i was busy with a bunch of other stuffs and lost track of this issue :sweat_smile:
I have tried fixing the requested changes, :smile:

authors: SumantxD coveralls


text:
feat: add operations to the components object

title: "feat: add operations to the components object"

This PR add ability to define reusable OperationObject inside ComponentsObject.

What's the use case driving this? 🤔 I see no issue discussing this feature.

There is no discussion in any issue (only in slack discussion - https://asyncapi.slack.com/archives/C0230UAM6R3/p1649669700248579), because I was wondering why we have channels/servers/messages in components and no operations. Simply use case is a possibility to use reusable operations between several AsyncAPI documents - you define in one file where you define only components (you treat one document as registry) and then you make references where you want.

Simply use case is a possibility to use reusable operations between several AsyncAPI documents - you define in one file where you define only components (you treat one document as registry) and then you make references where you want.

Yeah, understand the potential use case but I'm more curious if this is actually that has been needed at some point by someone (even if just you while doing an experiment or something). One of the guiding principles of the spec is Favor no change. I know we're not always respecting it but I think we should be more cautious by adding stuff that may not be necessary ever.

In version 3.0 we will have to add this. Is it better sooner or later?

You're not answering my question :)
And if we're adding it in v3.0, why bother adding it to v2.x? It's never been there and it's been fine. It can wait until v3 perfectly.

@fmvilas You didn't ask a question in the previous comment, and on the previous question you nodded to my answer, although you didn't fully agree 😄  - and no, there was no discussion and I have no real, production use case.
When we were adding channels and servers to the components in 2.3 it was also "not" a real use case (of course people complain about the lack of reusability of channels, but due to the fact that operations are strictly defined with channels the reusability of channels in >=2.3 still causes a big problem). We agreed then, that it is better to add things that we plan to add in 3.0 to 2.x, those that do not cause breaking changes. In my opinion, reusing operations themselves makes more sense than channels or servers, because they can be reused in several channels, and channels and servers can be used only once.

We agreed then, that it is better to add things that we plan to add in 3.0 to 2.x, those that do not cause breaking changes.

It's going to be a breaking change anyway because the operation object shape will change.

In my opinion, reusing operations themselves makes more sense than channels or servers, because they can be reused in several channels, and channels and servers can be used only once.

It does. And it introduces more complexity in the current spec major version when nobody asked for that. That's my point. We did not ask when introducing channels or servers and that's probably our fault. We should have questioned those features too given that v3 is in the works. In other words, I'd just continue evolving v2 if it's strictly necessary and useful for a real use case. I mean, it should always be like that but now more than ever.

Then I close the PR, if someone wants it in 2.5 I will reopen it.

You didn't ask a question in the previous comment, and on the previous question you nodded to my answer, although you didn't fully agree 😄

say what? 🤣

authors: derberg fmvilas magicmatatjahu

repo: asyncapi/spec


text:
[TOOLING] What about adding a 'Mocks & Tests' section ?

Hi AsyncAPI team !
I was looking at the Tooling page (https://www.asyncapi.com/docs/tooling) and would like to reference Microcks as a tool allowing you to:

Turn your AsyncAPI contract examples into ready to use mocks,
Use examples to test and validate implementations according schema elements.

I did not find any section that was fitting this category... so wondering about adding that new one: Mocks & Tests ?
As an inspiration, OpenAPI.tools has a Mock Servers section but I think that mocking is only one side of the coin.
What do you think ?

No problem !
Just found the tooling.md into the website repo. Pushing a PR in coming hours ;-)

repo: asyncapi/website


text:
docs: adding document for dynamic channel

Description
Added Dynamic channel name page.
It is a part of GSoD'23 project.
Related issue(s): fixes ##1511
** Previously worked PR:** #1959

/rtm

authors: alequetzalli mhmohona


text:
Add new group styling classes

Add new success, warning, danger, and disabled classes for application to element groups.

Completed.

repo: asyncdesign/webui


text:
Add flex-padding-* classes for padding all child elements using flex-* classes

Add the following classes:
.flex-padding-xs
.flex-padding-sm
.flex-padding-md
.flex-padding-lg
.flex-padding-xl

Completed.


text:
Dependencies not found (React)

Thank you very much for this addon. I tried it out in our codebase, but it didn't seem to work. I created a small demo project to show that dependencies are not found. https://github.com/donaldpipowitch/storybook-addon-deps-bug
$ git clone https://github.com/donaldpipowitch/storybook-addon-deps-bug.git && cd storybook-addon-deps-bug && yarn && yarn install
Any idea why? I thought I configured everything correctly.
Thank you :)

@donaldpipowitch really sorry for the delay, i was pretty busy and hope to get to your repo this week.
As a compensation, i will share here first what I have been busy with - “1-line functional testing”
https://gifyu.com/image/qtbT

Don't worry take the time you need. And niiiiice idea with the one line controls 👍

@donaldpipowitch - found it, by default the plugin filters stories as the usual names (stories.tsx etc). You ca change the filtering options from the options of storybook-dep-webpack-plugin, but i completely forgot the list the options in the readme, So I have now updated the readme - can you please check the last section Options.filter - and you should be able to adjust the re mask to your needs,
If not, the easiest 'fix' would be to rename your stories to the default naming too :)
Anyway, here is a screenshot of the addon working now:

If you also want to play with how much details to display, you can use more of a docs-only type setup like here:
https://github.com/storybookjs/design-system/blob/57cc9176a788efae9330a348744ed22114360b40/.storybook/preview.js#L14

I'll close for now as this will probably solve my issue. Thanks

authors: atanasster donaldpipowitch

repo: atanasster/storybook-addon-deps


text:
🛑 Wedding HTTPS is down

In c800369, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in 09817c0.

repo: atatkin/milos-uptime


text:
🛑 Wedding HTTPS is down

In 24c3a72, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in 2fdbdaa.


text:
🛑 Minted HTTP is down

In 68415f0, Minted HTTP ($MINTEDHTTP) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Minted HTTP is back up in c5da3cd.


text:
How to Separate Transactional and Promotional emails ?

I would like to separate Transactional  & promotional emails for a domain & also i don want to queue the transnational email while shooting the promotion mails .
Dinesh

At present there is only a single queueing mechanism to separate the processing of the queue based on the type of message. All messages are treated equal. At present, to achieve this you'd need a second installation of Postal.

Thanks for your prompt reply Adam . I know it is possible to prioritise the rabitmq queue. I will pass header with transactional and promotional email and based on the header I am gonna prioritise the queue. I hope it would be the right way to go.Could you please guide me which file I need to look out for?

repo: atech/postal

license: mit

license_source: bigquery


text:
Upgrade repository url in manifest

As advertised

thanks @steelbrain 😃

authors: silvestreh steelbrain

repo: atom-material/atom-material-ui


text:
Atom not respecting Electron CLI switches

This is a follow on from a discussion in Atom's Discuss
I'm using Atom 1.6, which is built on Electron 0.34.5. In the Electron docs it mentions the --debug and --debug-brk switches.
Running /Applications/Atom.app/Contents/MacOS/Atom --debug-brk=60131 hangs. Normally node processes print out that they're waiting for a listener before proceeding. Using --debug allows Atom to run, but as I'm running a test (--dev --test) I'd like the process to block so I can connect my debugger.
There may be other Electron switches that Atom also doesn't respect that I don't know of.

If someone can point me in the right direction of the CLI switch parsing I might be able to fix this.

repo: atom/atom


text:
Atom nightly breaks webviews (Electron 5.x API changes)

Description
Atom nightly now uses electron 5.x, which disables webview and nodeintegration by default.
1bc06505d5cccb452724c5628f6288787f16aa44 enables the nodeIntegration but webview is still disabled by default.
Could we have it enabled?
cc: https://github.com/ashthespy/Atom-LaTeX/issues/244

Hey @ashthespy, thanks for the report!
I will bring this up in our next meeting to discuss with the team, any extra information would be helpful:

any known drawbacks?
what's the motive? (whether this is a use case you are implementing or a known reported issue)

@lkashef Well, it was enabled by default in previous Electron versions. The use case (for me) is a tabbed viewer that renders a locally hosted pdf.js based pdf viewer. (Linked issue in the first post and workaround using an iframe for now)

Thanks @ashthespy that's pretty helpful, we will update the issue with any progress.

@lkashef Looks like this didn't make it to Atom 1.47.0?
Do you know when the next release with the fix is going to land? I don't feel particularly inclined patching stuff..

@ashthespy You are right, unfortunately it didn't, also wee don't have a published release schedule, but you can definitely check things out on Nightly and share with us any feedback.

On the other hand, have you considered using BrowserView since this seems to be the Electron way starting v5 (available in stable)

@lkashef Thanks for the heads up on the BrowserView - do you have an example of what's the best way to use this to create a view to use in a panel?

Hey @ashthespy, you are most welcome.
I think collaborating on the Atom's Slack or discuss would be more helpful, although here are a couple of thoughts that might help put you in the right direction.

BrowserView docs for the current supported electron version https://github.com/electron/electron/blob/v5.0.13/docs/api/browser-view.md
Check Atom's Markdown-Preview, it doesn't use BrowserView per-say, but it could be an alternative design, you might consider.

Communication Channels and Documentation Links

User Documentation — The Atom Flight Manual
Developer Documentation — Atom API Documentation
FAQ — The Atom FAQ on Discuss
Message Board — Discuss, the official Atom and Electron message board
Chat — Join the Atom Slack team

Hey, just wanted to say, this is extremely painful for a few reasonably popular packages. Maybe we can, like, fix this, backport it to 1.47 branch and release as 1.47.1? Because it's been 2 weeks since 1.47 released already, and it's getting pretty annoying to deal with it both for users and maintainers.

FWIW, BrowserView doesn't quite fill the same niche in Atom as webview tag does -- BrowserView is literally drawn over any element in Atom, so it's quite literally impossible to make it a part of Atom UI.

+1 to the above. Raises some pretty serious questions about beta testing if it breaks at least three packages with mass 100K+installation and is now still unfixed and un-reverted after several weeks. I fear this sort of thing will lead users to try other editors.

Hey @sean-codes, thanks for reaching out.
This fix is already available in Atom Nightly, we are also working on a release to patch this issue in stable and beta.

authors: ashthespy aubreyz lierdakil lkashef


text:
Add portable version of Atom

I don’t really stick to one computer to program, and some computers don’t have editors. Currently I use Sublime Text portable, but it would be great if there was a portable version of Atom.

Atom is a great little editor but as someone who needs to code whilst on the move eg trains, buses, etc and have it installed on a USB drive I could do with Atom being portable. To fill my needs for the present I use a portable version of Notepad++ but ultimately would prefer just to work in Atom, hopefully this will become a reality soon. By the way thanks for the great work you have done to date.

Some folks have committed patches to Squirrel to allow you to use it in a Portable way, if the Atom Team wants to support this scenario I'd help out with it

@paulcbetts We would love to support this. We have a lot on our plate already, and honestly none of us are super windows inclined. Any help on this would be much appreciated. :+1:

Per the discussion on #4980, we should cover Linux too.

@benogle @paulcbetts that sounds awesome! I would be happy to jump in testing as soon as a preliminary version is available.

@paulcbetts is this something you would be doing, reading @benogle's comment, or is this something one of us should provide a PR for where you can help with?
Just to make sure we're not waiting for each other :)

@CumpsD Lemme look into what it would entail, then I'll ping back this thread

Is it possible to reduce the number of files for the portable version? I count about 8000+ files and that is not very sane for a flash drive. Can it be reduced to a big binary and a couple of files?

@stavpup Atom could do this if they switched to using ASAR, but that's a non-trivial undertaking and I don't know if/when they plan to do that.

Hello. Any updates on this?

Hey everyone, I've successfully gotten a portable 0.176.0 windows installation working, based on @bclindner's post: https://github.com/atom/atom/issues/2939#issuecomment-62586621
The only issue I've run into so far is that it'll still display the user's home path for the location of the .atom folder. Functionally, this will make atom use the exe's folder for .atom.
Here's the updated info:
Note: change every instance of ~/.atom to ./.atom
resources\app\apm\.apmrc
line 1: cache = ~/.atom/.apm
resources\app\src\browser\atom-application.js
line 663: configDirPath: fs.absolute('~/.atom'),
resources\app\src\atom.js
line 114: return this.configDirPath != null ? this.configDirPath : this.configDirPath = fs.absolute('~/.atom');
resources\app\src\coffee-cache.js
line 14: cacheDir = path.join(fs.absolute('~/.atom'), 'compile-cache');

i don't really belong posting here but it's a topic I have been following. cause I to really want to move to Atom.  I'm not a coding/config guru btw.
@nuxonom that worked to get the .atom folder out of roaming, but there is still a plain Atom folder in there. does it contain anything that needs to "travel" to be portable? or is it just a temporary place that will just be recreated on the next computer you plugin into without losing anything? apologies again since this is more of a support question that a contributing one.

I don't understand - the available .zip version is the portable version or there are other issues?

Good question, it looks like there is a atom-windows.zip on the release page. But I cannot see anything for Linux...

@Ricain look at #5385. Seems like Atom can already be made "portable" but it requires setting an ATOM_HOME environment variable. I'd still like it if Atom would also look for an .atom or .config or whatever subdirectory in the application directory. This would avoid the hassle of dealing with env vars.

@iliyang thank, I will take a look at it.

I wrote my self a simple boot script, and it works fine:
@echo off
pushd %~dp0
if not exist .atom mkdir .atom
set "ATOM_HOME=%~dp0\.atom"
atom

@Ricain Did you have time to investigate the check for a .atom (or .config) profile directory at launch?

Okay, so now that #5385 is working, how do I set the ATOM_HOME env var? I'm working on a project between school and home off of a flash drive. How can I get this configured? Thanks.

In case all you non-Windows people are curious, the "installation" process of portable apps should be nothing but copying/extracting files into a specified folder. No environment variables (which are handled via the OS), registry keys, or entries in the "Add/Remove Programs" listing are allowed.
The use of the user's profile folder is discouraged (i.e. it should not be the default installation location), although not forbidden. Most portable apps I've used default to placing the program's files in a \[program_name] folder, which makes it easy to select a thumbdrive as the destination.
All of a program's settings should be stored in a file inside same folder where the program is located, or in a subfolder thereof.
In essence, if you delete the one folder where the program is installed, there should be absolutely no residue or indication that that program was ever on the computer (ignoring delete-recovery aspects such as the Recycle Bin and Windows' self-maintained list of recently run programs, which can't be helped).

@JixunMoe 's script wasn't work for me.
environment: Windows 7 + atom-windows.zip(0.209.0)
error message window:
A JavaScript error occured in the browser process

Uncaught Exception:
Error: Failed to get path
  at Error (native)
  at Object.<anonymous>
(C:\Users\MyName\somewhere\Atom\resources\atom.asar\browser\lib\init.js:96:41)
  at Object.<anonymous>
(C:\Users\MyName\somewhere\Atom\resources\atom.asar\browser\lib\init.js:104:4)
  at Module._compile (module.js:452:26)
  at Object.Module._extensions..js (module.js:470:10)
  at Module.load (module.js:347:32)
  at Function.Module._load (module.js:302:12)
  at Function.Module.runMain (module.js:493:10)
  at startup (node.js:120:16)
  at node.js:877:3

It seems like be caused from that there is no directories .atom\AppData\Roaming.
So I changed the script like follows and it works for me.
# In order to remove cmd window, using start :-)
@echo off
pushd %~dp0
if not exist .atom mkdir .atom
if not exist .atom\AppData mkdir .atom\AppData
if not exist .atom\AppData\Roaming mkdir .atom\AppData\Roaming

:: Trick emmet or other plugin to think profile directory is in our data directory
set "USERPROFILE=%~dp0\.atom"

:: Set Atom base directory
set "ATOM_HOME=%~dp0\.atom"

:: Boot
start atom

http://portableapps.com/node/43424
Would love to see a PortableApps version.

"John T. Haller
For future reference, this requires .NET 4.5 which is only bundled with Windows 8 and higher. Windows 7 and lower (the vast majority of Windows machines) requires .NET 4.5 to be installed with administrative rights."
To comment on that, windows 7 machines will upgrade to windows 10, so that is not an issue.
http://portableapps.com/node/43424

For non-Windows devs, here are some definitions of what constitutes a portable app:

http://portableapps.com/about/what_is_a_portable_app
http://www.portablefreeware.com/about.php
http://superuser.com/questions/137894/whats-the-difference-between-portable-and-install-versions
http://www.rlvision.com/blog/what-is-a-portable-application-and-why-should-you-use-them/
http://www.rarst.net/software/portable-definition/
...

This worked for me too! (Also have had success in converting to a PortableApps format, but not ready for primetime).
The only problem that I have found so far is trying to get linter-php to work. It works with an absolute path to php.exe, such as "\Programs\PortableApps\AtomPortable\App\Atom\php\php.exe". However, when I give a relative path like "App\Atom\php\php.exe" it does not perform the error checking.

@iliyang nope I did not yet and I will probably won't since school stopped: I tried on school's Debian with no root access... (sorry for this late answer)

Please reopen. Atom is not portable. It saves temporary files to the root volume, and the current hacked batch-method isn't deployable.

This needs re-opening. Installed packages do not transfer from one machine to another.
Tested by installing merge-conflicts package into the zip version extracted into dropbox, then opening on another machine.

There is a Linux portable version?

Why is this closed? It doesn't work for me? I either have to set the ATOM_HOME environment variable on the target machine or else the directory will always ~/Atom . That doesn't make it portable.

Please reopen.

Once this becomes portable I can actually start using it, as I switch between two computers each day this is essential for me!

@mwyatt, there is a Package to sync configs, packages, etc, between different computers: https://atom.io/packages/sync-settings
It's really useful, easy con configure, using Gists, and you can use it for now until Atom Portable is released. :smile:

I have my ATOM_HOME variable set to a Configs/.atom folder in my Dropbox on all three of my computers, and they are always synced that way.
It's correct that this isn't truly portable, but it's pretty quickly done and does the job.

@batjko :+1:
I will try with owncloud!

Thanks @nelson6e65 + @batjko will try these out!

:+1: Please reopen this. It would be epicly awesome!

Please reopen.

It seems like we could do some more work to make this easier, maybe detect whether to run in Portable Mode™ based on process.execPath

need xD

@paulcbetts I think what people still wait for is a Portable Mode™ that comes out of the box. For example the zipped release version could be made to be fully self-contained (not relying on env vars etc)
They don't want to have to set any environment variables, use command line switches or whatnot.

@batjko That may very well be the best way IMHO.

@batjko I think we're violently agreeing here, basically we use process.execPath to detect whether we're installed, then if we're not installed, we operate in Portable Mode.

The problem with that approach is if Atom is "installed" in portable mode in Dropbox or a USB drive, and an attempt is made to run it on a computer where there is a pre-existing installation of Atom...   you see the issue.
I'd strongly urge you to implement it as a portable app according to the PortableApps.com spec: http://portableapps.com/development

Is it a huge effort to maintain a fully independent portable release - i.e. without conditional launch mode checking, and without an installer, just the ready-to-go folder with a local .atom inside the release directory?

I agree that it could be a pain to maintain a PortableApps-style release. I, and I also hope most other users, would be perfectly happy with an .atom folder inside the installation folder, as long as everything remains completely encapsulated and no files are written anywhere outside the installation folder. Such a simple structure would also hopefully facilitate automatic updates.

Is it a huge effort to maintain a fully independent portable release - i.e. without conditional launch mode checking, and without an installer, just the ready-to-go folder with a local .atom inside the release directory?

I think it'd probably be super easy, I might try to make a patch for it

A year ago I made a copy mostly portable by simply having a .atom folder in the application's folder. The only real issue is duplication and hardcoded values through out the app to determines the location of the .atom folder. Ideally there should be a single global function or variable that holds the location of the .atom folder, then the rest of the app and all plugins get the value from this global func/var. In good api design this is how an app should be setup. I would of done these myself but I dont like coffeescript and I feel it was a mistake to use coffee script in developing atom, but that's another issue entirely. The changes I did was to the javascript of the compiled atom btw. Look at previous comments and examples I made in this thread literally a year ago. Which is kinda sad that after a year this is still an issue.

I would prefer to have a simple zip file. It's easier to set up and use
than a PortableApps installer. And I'm already used to a similar workflow
with the Linux global install version. My school uses Windows almost
exclusively, which necessitates having a portable version to take around.
It would be incredibly convenient.
On Wed, Aug 19, 2015, 10:51 sketchpunk notifications@github.com wrote:

A year ago I made a copy mostly portable by simply having a .atom folder
in the application's folder. The only real issue is duplication and
hardcoded values through out the app to determines the location of the
.atom folder. Ideally there should be a single global function or variable
that holds the location of the .atom folder, then the rest of the app and
all plugins get the value from this global func/var. In good api design
this is how an app should be setup. I would of done these myself but I dont
like coffeescript and I feel it was a mistake to use coffee script in
developing atom, but that's another issue entirely. The changes I did was
to the javascript of the compiled atom btw. Look at previous comments and
examples I made in this thread literally a year ago. Which is kinda sad
that after a year this is still an issue.
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2939#issuecomment-132625692.

No reason not to have both.
FYI, one major advantage PortableApps has over just a zip is that it offers automatic app updates.

+1 for portable mode

+1

+1 for portable mode

@impinball
Am I missing something?
If you don't want to use the PortableApps menu you can use the self-extracting zip-files directly.
You'll have to remember to update manually though.

@kdmaas
It's not so much the menu. I just prefer unzipping a zipball in a few steps through the standard instead of clicking through about 6-10 screens in a pretty useless GUI that does effectively the same thing.
Unless Atom modifies the registry (which it doesn't appear to, even in a global install), I don't think there would be much advantage to an installer that is just a glorified self-extracting zip file. You might as well use 7-zip for that - it would accomplish the same thing.
I also don't think that there would be a lot of work to make this zip-file portable. IMHO it would be easiest if Atom included a way to change the user path (i.e. the return value of os.homedir()) at the time of initialization. It's something that could also be done via setting the %userprofile% variable in a way local to the application.

+1

+1, only thing keeping me from using atom

+1

Just chiming in with my support for a portable version, I use Atom off of a flash drive for coursework and losing custom settings/packages is less than optimal. I'll try the suggestions put here by others until Atom is truly portable :+1:

:+1:

+1

+1

:+1:

This is being worked on in https://github.com/atom/atom/pull/8442, so there is no need to +1 this and in so doing, notifying 52 people. As a result, I'm locking this issue for the time being. Feel free to subscribe to the PR if you're curious about the progress being made.

This is now merged into master as part of #8442 and friends, and will show up in the next release! Thanks for the feedback all

💥 🎉

authors: CraigLager CumpsD DominikLevitsky Ivan171 JerichoDefeated JixunMoe Machou Ricain Sisyphuss Syenta Zireael07 alexchandel amroamroamro batjko benogle bhack bitbonk capSAR273 d10 docterry dumpsters iliyang impinball jamescostian javiglesias kdmaas kleerkoat lee-dohm mwyatt nelson6e65 nengxu notnsane nuxonom paulcbetts proimage sketchpunk snuggles08 softwarespot spencersager stavpup thomasjo tknerr war59312 yuki-takei


text:
ctrl-o in Debian always opens "Recently Used" in file chooser

This is exactly the same issue as #3618 .  I'm re-submitting an issue because the old fix does not work anymore as a result of AtomWindow.projectPath no longer existing (assumed to be the result of #770 where multiple project paths are now supported.
I was unable to figure out how to get console.log statements or errors reported to the dev console.  If someone can shed some light on how to get that working, then I can submit a PR.

This also happens in Mac OSX. I would prefer to "open the currently open file's folder as default."

@olsonpm: The title of this bug is too specific:

The correct behaviour is to open in the directory of the currently open file
Mac OSX and Windows are affected too

Can you please update the title to something like:
"Ctrl-O should open the file chooser in the current directory".
As the original report in #3618 stated:

Using keyboard shortcut ctrl-o in Ubuntu launches open file dialog with "Recently used" as default
folder. The default in basically all other apps (including Sublime Text) is to open the currently open
file's folder as default.
Yes, the tree view is there to quickly open files from current directory, but breaking convention is
bad.

I agree. Please fix Ctrl+O. I am having a very hard time with Atom's current behavior.

@sneakypete81 - I kept the title the same in order to keep it consistent with the original issue.  Changing the title assumes something different is occurring - I would like to keep it the same for that purpose.

Confirmed also in Ubuntu 14.04 with Atom 1.2.2.

I am a new atom-editor user who was previously using KDE's kate and kile. I am on Netrunner Rolling Release 2015-09, which is a derivative of Manjaro Linux, and ultimately Arch. The version of atom editor is 1.2.4.
Ctrl-O gives me "Recently Used" as reported here. What is worse, some of recent those files are PDFs, not intended for editing.
Is there an installable package that allows circumventing this problem as quick workaround?

@kleinbottle - if you find one please let me know.
The workaround I've been using is to utilize a different workflow.  I'm now accustomed to opening 'projects' (for which there are many plugins depending on how you want to manage those).  Within an open project, the fuzzy finder works very well - and there's even an "open buffer fuzzy finder" which  searches the files that you currently have open.
The above workflow doesn't work well for one-off files unfortunately - for which I use the tree view or the command line.

@olsonpm there are still times when I want to use something like the file picker even within a project, especially for large projects and/or projects with similar filenames (e.g. I have a file “card.coffee” on client, one on server, one on models, plus “card.jade” on client).
The workaround I've been using for that is advanced-open-file, but it's not quite good enough.

I guess mainly I dislike the tree view? :-)

@lalomartins - Of course is natural to open your OS's file explorer and find a file via the behavior you're used to.  Either most people are used to opening up the recent file list, or they just aren't using the file explorer.
Thanks for mentioning advanced-oopen-file.  I'll have to take a look

Thanks for suggesting advanced-open-file @lalomartins.
As @olsonpm has put it, I so much like the file selector in KDE where the "Recently Used" option was not pre-selected and so did not intrude in the way I work. I wonder why something so customizable as atom-editor does not have an option for this default behaviour.

Any updates on this? :)

@stilliard It's likely safe to say this problem doesn't impact enough people to warrant development time against - unless you have the time to do it yourself.

Thanks @olsonpm

I'm sorry @olsonpm, and I'm more than happy to try my hand at a patch, but — how the blazes does this doesn't impact enough people? “Safe to say” even? Basically, ctrl-O is broken to the point of uselessness. If you think not enough people use application:open-file, take it off the menu and rebind the keys to something that works.
It's extra useless because Atom also doesn't do whatever needs to be done for files to appear on Recent — so what you get there is pretty much never what you want.

Hmm sorry, you're the reporter and you're saying what you observed, not a developer expressing a project view. I'll shut up and wait for an “official” answer then.

Hmm sorry, you're the reporter and you're saying what you observed, not a developer expressing a project view. I'll shut up and wait for an “official” answer then.
BTW, this needs the “linux” flag removed, and maybe the title rewritten. Maybe taking the Debian reference off would attract more attention?

@lalomartins haha - not a problem.  We're not in agreement over whether this impacts enough people.  We can only assume the number of people this negatively effects are the number of people who comment on this thread which is a single digit.
I haven't used application:open-file to notice its broken behavior, but I'll trust you're right on that.
I changed the title to what @sneakypete81 suggested.  Due to the issue being the same, I wanted to keep the title consistent.  Since it is not linux specific however I agree you and him are correct.  My bad on that.

application:open-file is the internal command ctrl-o (or cmd-o) is bound to :smiley_cat: sorry if that confused things, I wanted to be unambiguous and include linux, win, mac keybindings plus the menu File → Open

Nah I got that - and I used it for the same purpose :)

I suspect the problem is here (and yes, I still want this to be fixed).
https://github.com/atom/atom/blob/ec66a66bb3c4be92b01f861e210f429e4737da7b/src/browser/atom-application.coffee#L612
It's possible that we're unable to set the default path on linux, despite trying this:
    if process.platform is 'linux'
      if projectPath = @lastFocusedWindow?.projectPath
        openOptions.defaultPath = projectPath

It does not even try to set the default path for darwin.
It's also possible that the implementation of dialog.showOpenDialog ignores the defaultPath part of its options.

Anyway opening in the project dir was a work-around, the correct behaviour is the dir where the current file is

I've tested with a starter electron app and dialog.showOpenDialog defiantly works with defaultPath, so no issue in the core electron at least (unless fixed more recently).
Also It looks like the save dialog works, so maybe comparing the open to save dialog code will help.

Yeah, Ctrl+Shift+S does work.
The Linux menu items are here: https://github.com/atom/atom/blob/dd1eb750fe95e4ab9bfeef294d98d1e738620102/menus/linux.cson
These commands (regardless of system) seem to be routed through here:
https://github.com/atom/atom/blob/38d6ded9c45bacfc0f5145e576468d3dbfddcbcb/src/register-default-commands.coffee
We can see the difference between core:save-as and application:open-file is that the former is handled by the model as @getModel().saveActivePaneItemAs() while the latter is handled separately by the application ipc.send('command', 'application:open-file') as seen in https://github.com/atom/atom/blob/ec66a66bb3c4be92b01f861e210f429e4737da7b/src/browser/atom-application.coffee#L172

Definition of saveActivePaneItemAs: https://github.com/atom/atom/blob/28517563ebb6a73da1e7b03d1c7fe36ae8d0e611/src/workspace.coffee#L637
Pane (and Item) spec: https://github.com/atom/atom/blob/db74f4a8f0656411ce39d51b05e465c990061301/spec/pane-spec.coffee

I do not know CoffeeScript, but unless I'm mistaken, we can get the default path from this:
@getModel().getActivePane().getActiveItem().path
We may need a few ? if some of those things don't exist at runtime.

I think what I've proposed has a good chance of working. While I could make a pull request, I don't know how I would test it. Can someone with experience building Atom give this a try?

I just checked the build steps - seems pretty minimal.  If you make the changes and host it on a fork, I'll pull -> build -> test your fix.

Thanks, that sounds good to me! I'll let you know when I'm ready.

If I've done it correctly, you can see it here: https://github.com/afandria/atom/commits/patch-1 (afandria/atom on branch patch-1)

Alright.  I'll have time this weekend - aiming for saturday afternoon.  I'll get back to you Sunday at the latest.

Thanks, looking forward to it!

Quick update - nothing happens when I run this.  No console errors, no dialog, nothin.  I tested this against atom's master which does prompt as expected.  I'm looking into it myself now.  Unfortunately the build process takes a while on the vm I spun up.  This is new territory for me though - I may not be debugging efficiently.

Well I'm giving up again for the same reason I did last time.  I write console.log/error statements, I know I'm running through those log statements, but no output is shown in the dev console.

@olsonpm Are you running Atom in dev mode when you test those log statements? Where did you clone the Atom project?

No - from what I ready about dev mode, its use is mainly to prevent the need for window: reload after package changes.  And the location for where I cloned the repo doesn't matter.  Initially I was building->installing atom within a clean debian 8.2 vm.  After becoming familiar with the process, I started doing it on my personal laptop (also debian 8.2) attempting to avoid any vm performance penalties.

@olsonpm The code in src/browser/atom-application.coffee runs in the browser process. The inspector only sees the render process. Stuff like this that interacts with the OS happens in the browser process. You can run atom with the flags -fw to see this output.

@jrkoenig - Thanks much, that makes sense.  I'll give it a shot this weekend.

Thanks so much @jrkoenig.  I'll test your PR when I get a chance.

@afandria The bug fix you posted all those days ago did not work, I'm sorry to say, due to @getModel() not being available anywhere in browser files. Though your idea was spot-on.
I've been working on this a bit myself with a small group of people and have a few questions, but the most important is simply: why is the open-file code contained within the browser process? I can understand that area having the code for opening all the files on start, since they have to initialize and populate everything, but I don't understand why this single function is there also. Why isn't it next to the save function in workspace.coffee? Perhaps I just don't understand what the code within the folder title "browser" does, or the way opening files works in Electron though.
In any case, no reference to model or workspace is available in any files in the "browser" folder of Atom as far as I can tell, so there doesn't yet seem to be a chance of ever getting the active project (and the associated path) in order to resolve this bug by setting the default path. We've actually tried passing the model along through IPC, but that hasn't had much luck either. If anyone is still interested in this, information would be greatly appreciated.

I typed this long-ish text, then I read a few messages back and I noticed there's already a PR, so my post is obsolete.
I'm going to post it anyway, in case there's a problem with getting the PR merged, but as it is consider it a message from an alternate universe or something.

2¢ — if this is a huge project, it might be worth it as a temporary fix to open the file chooser in the direction it was last. So, whenever you select a file using the chooser, store the location as state somewhere, then next time start in the same place, if available. It would already be a lot less annoying, I believe, and that's what browsers do with the “save as” dialogue.
Alternatively, figure out how to interact with the various OSes “recent” list, so when it opens in that view, it will at least contain the last place(s) where you opened a file.

@lalomartins Those are pretty good ideas. I might accept the first one myself (saving the location as state somewhere and then just going back to it each time). That behavior almost seems better to me than the "correct" behavior of opening in the current directory. Do you think a fix that does that would be accepted?
And as for the PR that's been out for a while now, that one most likely will not pass. I actually get an error when I try to run it.

I would accept it, at least ;-)

@delliott2016: Thanks for trying it out. It's too bad it didn't work. :(

@lalomartins Good enough for me. ;)
@afandria No problem. It looks like this particular code is just in the wrong place. Anywhere else -- literally almost anywhere -- and your fix would have worked.

Fixed in #11618, thanks to the hard work of @delliott2016.

@delliott2016 Thank you!

@afandria You are most welcome. It was only possible thanks to your research and hard work as well!

This sounds like the problem is long resolved. Or is it an optional setting that needs to be activated somewhere? Because I’m using Atom 1.8.0 on Linux and have run into the same problem.

@Telofy it should be fixed starting in Atom 1.9.0.

Still not fixed for "add project folder" though. But yes, ctrl-o works fine. Testing on 1.12.3

@jrial Can you please create a new issue?

Thanks for this fix! This was a huge pet peeve of mine.

authors: 50Wliu JavaScriptDude MadLittleMods Telofy afandria delliott2016 jrial jrkoenig kleinbottle lalomartins lee-dohm mnquintana monocasual olsonpm sneakypete81 stilliard


text:
[WIP] Use ohnogit

We’ve pulled the brains of GitRepositoryAsync out into its own package: https://github.com/github/ohnogit
This lets others use it for projects other than Atom.

@atom/core FYI. The conversion was pretty mechanical so I don't expect any fallout but feel free to cc me if you see something suspicious.

Quite a name!

authors: joshaber nathansobo


text:
[WIP] Upgrade to Electron 2.0.0

This pull request is a work-in-progress. Electron 2.0.0 includes a few breaking API changes that we'll likely need to work through in order to get Atom running smoothly on Electron 2.0.0.
TODO

[x] Get CI passing
[ ] Run through Atom's Electron upgrade test manifest to identify any regressions

/cc @codebytere

The core render tests are passing now. 😅
Only two packages have failing tests: the archive-view package and the github package.
I'm hopeful that we can resolve the archive-view failures by:

Publishing a new release of ls-archive that incorporates with the changes in https://github.com/atom/node-ls-archive/pull/10
Publishing a new version of archive-view that depends on the new version of ls-archive

I'll look into the github package failures next.

Electron 2.0 uses Node 8.9.3. Atom's build currently uses Node 6.9.4 [A]. Should we update Atom's build to match the Node version used in Electron?
@as-cii: Do you happen to know whether the Node version in the Atom build needs to match the Node version that's in the version of Electron that we're using?

[A] There are a handful of places where we specify a dependency on Node 6.9.4. It's in .travis.yml, appveyor.yml, and circle.yml. And in the flight manual, we say that you need Node.js 6.x or later to build Atom.

On the other hand, we should probably still have something checking that Node.js v6 still works to build Atom, at least until it's maintenance period ends or we drop support for it due to this:

And in the flight manual, we say that you need Node.js 6.x or later to build Atom.

Lol, what
AssertionError: More than one application to run tests against was found. /home/travis/build/atom/atom/out/app/node_modules/github/lib/atom,/home/travis/build/atom/atom/out/app/node_modules/github/test/atom,/home/travis/build/atom/atom/out/atom-1.28.0-dev-358d6dd-amd64/atom

The lib/atom folder within atom/github is relatively new. I'm guessing that's just tripping up some path location logic?

Okay, that's fixed. Those two dialog cancellation tests are still timing out on CircleCI, though.

[x] Get CI passing

✅😅
Big thanks to @smashwilson. :zap:

Nice work!  I'm building this branch now to dogfood it until we're ready to merge this PR.

Built and ran Atom successfully from this branch!  One weird thing I noticed, our SVG-rendered Atom logo in the About screen is broken:

Did something change in the Chromium renderer related to SVG?

@lee-dohm let me know that this problem shows up in 1.28-dev without the Electron 2.0 change, so that's not the culprit here!

I'm super happy to see this getting unstuck. Thank you @jasonrudolph and @codebytere for doing this! :green_heart:

@daviwil One weird thing I noticed, our SVG-rendered Atom logo in the About screen is broken

Seems unrelated to this branch, happens on master too. Made a new issue: https://github.com/atom/about/issues/78

For my own reference, here's the stacktrace that @jasonrudolph is seeing:
Uncaught (in promise) Error: Cannot find module '../node_modules/string_decoder/lib/string_decoder.js'
    at Module._resolveFilename (module.js:543:15)
    at Module._resolveFilename (/Users/j/github/atom/out/Atom.app/Contents/Resources/electron.asar/common/reset-search-paths.js:35:12)
    at Function.get_Module._resolveFilename (/Users/j/github/atom/out/Atom.app/Contents/Resources/app/src/module-cache.js:354:58)
    at Module.require (file:///Users/j/github/atom/out/Atom.app/Contents/Resources/app.asar/static/index.js:40:43)
    at require (internal/module.js:11:18)
    at customRequire (/Users/j/github/atom/out/Atom.app/Contents/Resources/app/static/<embedded>:96:26)
    at get_Decoder (/Users/j/github/atom/out/Atom.app/Contents/Resources/app/node_modules/split/index.js:12:37)
    at split (/Users/j/github/atom/out/Atom.app/Contents/Resources/app/node_modules/split/index.js:20:28)
    at /Users/j/github/atom/out/Atom.app/Contents/Resources/app/node_modules/what-the-status/index.js:37:18
    at new Promise (<anonymous>)
    at parse (/Users/j/github/atom/out/Atom.app/Contents/Resources/app/node_modules/what-the-status/index.js:16:16)
    at /Users/j/github/atom/out/Atom.app/Contents/Resources/app/node_modules/github/lib/git-shell-out-strategy.js:614:60
    at Generator.next (<anonymous>)
    at step (/Users/j/github/atom/out/Atom.app/Contents/Resources/app/node_modules/github/lib/git-shell-out-strategy.js:104:197)
    at /Users/j/github/atom/out/Atom.app/Contents/Resources/app/node_modules/github/lib/git-shell-out-strategy.js:104:367
    at <anonymous>

@jasonrudolph: I suspect the committing problem is a regression in Electron's asar integration - the fs-extra (or fs) module is no longer able to see directories within /Users/smashwilson/src/atom/atom/out/Atom.app/Contents/Resources/app.asar/.

Sidenote: I really really wish the package tests that run as part of the atom/atom builds ran against the snapshotted and .asar-bundled code. There are a host of issues that can be introduced in that process and we have no way currently of catching them.

I suspect the committing problem is a regression in Electron's asar integration - the fs-extra (or fs) module is no longer able to see directories within /Users/smashwilson/src/atom/atom/out/Atom.app/Contents/Resources/app.asar/.

@codebytere: Is this something you can help us with?
How to reproduce:

Install Atom built from this branch [atom-mac.zip]
Open any git repository in Atom
Change a file and save it
Open the git tab and stage the changes
Click the "commit" button
Observe that the change was not committed
Open the console and observe the following error:

Uncaught (in promise) Error: ENOTDIR: not a directory, copyfile '/Applications/Atom.app/Contents/Resources/app.asar/node_modules/github/bin/git-askpass-atom.sh' -> '/tmp/github-11848-53871-116kyba.1tjh/git-askpass-atom.sh'

Full-Width Alphanumeric (Google) - Japanese layout  (https://www.google.co.jp/ime/)
This should be tested on macOS
macOS	:

[ ] ✅   Verified

@Ben3eeE @ungb: Can you help me understand how to test this item from the test plan ☝?
I installed and enabled that keyboard layout, but I don't know how to tell if it's behaving correctly.

@jasonrudolph I believe that item comes from https://github.com/atom/atom/issues/15696 and https://github.com/atom/atom/issues/15783. We should probably reference these issues in the test plan and expand the steps

@jasonrudolph possibly! flying back to durham today, sorry for late follow-up!

@jasonrudolph Running this branch as part of daily work to see if I notice anything. I also tested some of the items in the test plan. Most of the Windows things are checked off already though :zap:
Big Files:
It seems the rendering limit is now ~2 million lines which is a huge improvement and the bad rendering is no longer happening and we are back to everything just being black. We still can't click on the content past ~1 million lines because we never get a click event. The vertical scrollbar limit has also seems to have increased and is now the same as the rendering limit. I need to get another "really big file" soon because mine is only 2.8 million lines long :sweat_smile:

Loss of subpixel AA:
I verified this and checked it off.

@codebytere: In case it helps, regarding the problem committing from the GitHub package (i.e., the suspected asar issue), it seems to be due a change that occurs somewhere between Electron 1.8.6 and Electron 2.0.0.
Committing from the GitHub package works when using the Electron 1.8.6 build of Atom from https://github.com/atom/atom/pull/16755.  But it fails when using the Electron 2.0.0 build of Atom from this pull request.

atom-mac.zip @ Electron 1.8.6
atom-mac.zip @ Electron 2.0.0

It seems that Atom loses subpixel rendering on macOS with Electron 2.0. (Subpixel rendering is working on Windows 10 and Ubuntu.)
Steps to reproduce:

Open a new buffer
Type any text (e.g., abc)
Take a screenshot
Zoom in real close
Observe absence of subpixel rendering

Atom 1.27-beta (using Electron 1.7)

Atom 1.28-dev (using Electron 1.8.6)

Atom 1.28-dev (using Electron 2.0.0)

@codebytere @ckerr: Is this something you can help us resolve?

@jasonrudolph Depending on the DPI of your screen, this may be expected. I'll try to find the Chromium bug tracker references I mention there for more details.

@jasonrudolph Depending on the DPI of your screen, this may be expected. I'll try to find the Chromium bug tracker references I mention there for more details.

@lee-dohm: Thanks for pointing that out! That inspired me to check on my Retina display, and I am indeed seeing subpixel rendering there. So, I'm going to remove that item from the list of regressions related to this upgrade.

Here's a regression I'm seeing: branch name and push/pull status bar icons now show an underline when hovering whereas they didn't before.

I'm seeing: branch name and push/pull status bar icons now show an underline when hovering whereas they didn't before.

@50Wliu: Thanks for pointing that out. I'm pretty sure that's a change in the GitHub package, and not a result of the Electron upgrade. I installed Atom from the current master branch (using Electron 1.7.14) and then installed github@0.14.0-3, and I'm seeing those same underlines.
I'll ping the folks working on the GitHub package to see if they're aware of that change.

I'm trying to test the final item in the checklist, but I think the repro steps might be out of date:

Install Atom on Ubuntu KDE.
Enable kde plasma global menu in System Settings -> Application Style -> Widget Style -> Fine Tuning tab -> Menubar style -> Application Menu widget -> Add a menubar Panel to desktop

In the "Fine Tuning" tab, I don't see anything about "Menubar style."

@Ben3eeE or @daviwil: Would either of you happen to know what I need to do to replicate these setup steps? I'm using Ubuntu 18.04 and this version of KDE:

authors: 50Wliu Arcanemagus Ben3eeE ckerr codebytere daviwil jasonrudolph lee-dohm simurai smashwilson


text:
Tab titles are not based on remote paths for guests

Has this been solved with RFC-002, or is this still an issue?

Has this been solved with RFC-002, or is this still an issue?

@CaptainJohnyAppleSeed: I think the behavior that @nathansobo observed was due to a bug somewhere that prevented the tab title from reflecting any path at all. 😬 But, since we haven't seen this issue in 5 months, and since we don't have steps to reproduce it, I'm going to close this issue. If anyone runs into this issue, please let us know.

repo: atom/teletype


text:
gradients upgrade

@shepaop voici une MR pour upgrader les gradients,
j'ai eu besoin de gérer les variantes de gradients sur un projet, je l'ai donc gérer en static en surchargeant gradients.process.js sur mon projet mais je me suis dit que ça pourrait être utile de les gérer en params pour les prochains projets dans le design-system
j'en ai profité pour supprimer du code mort et prendre compte également le type radial
il reste un léger problème callage en hauteur dans le styleguide mais pour ça il faudrait faire un upgrade dans les repo de framework (drupal/starter_theme_AFW_source, drupal/olema_AFW_source, atomic-framework/framework...).
à dispo pour en discuter si besoin.
Eric

Closing because gradient management is more an edge case for common design-systems.
Can be added manually for custom purposes.

authors: Ricozor shepaop

repo: atomic-framework-project/design-system


text:
Add flag for find_container, find_ticker, find_realm, etc for is_verified_only=True

#126

Very nice, thank you!

repo: atomicals/atomicals-electrumx


text:
Update build matrices and set OTP27 as the default

Update Linux Build matrix to favor more compilers, three latest OTP versions, while maintaining builds from 21 to master, reducing combinations from 46 to 39
Update Run tests on BEAM workflow to include OTP27
Update build and test on other Linuxes to use OTP27
Fix test_io_lib for OTP27 (including workaround for https://github.com/erlang/otp/issues/8606)
Fix compilation with gcc-14

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).
SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

I'll update comment in another PR then, adding support for ~kp.

repo: atomvm/AtomVM


text:
Add option for hosts to use k8s dns

This commit provides the option to set up the host to use kubernetes cluster DNS service, meaning that pods running in the host network namespace can access the cluster (required for ceph, and possibly other system services).

Please review this change prior to merging.

repo: att-comdev/halcyon-kubernetes


text:
Default-bundled css + js should use only from reveal.js core.

Currently
Anytime include files are:

revealjs/css/reveal.css (from builder class)
revealjs/lib/css/zenburn.css (from builder class)
revealjs/js/reveal.js (extension config)

Expected
revealjs/lib/css/zenburn.css is theme of highlight.js.
It is not minimum component of reveal.js, it should be removed.
Refs

Improved from https://github.com/attakei/sphinx-revealjs/issues/27#issuecomment-631970588

Fixing on https://github.com/attakei/sphinx-revealjs/commits/feature/extra-css

Fix by 0.12.0

repo: attakei/sphinx-revealjs


text:
add "hacktoberfest" tag

Ineligible Repository
Your PR was submitted to a repository that is not participating in Hacktoberfest. Maintainers of the repository can add the "hacktoberfest" topic to their repository if they wish to participate.

@itsrahulhere thanks for the concern, I've added hactoberfest as label.
happy coding :)

It is still showing Ineligible Repository.
Ineligible Repository
Your PR was submitted to a repository that is not participating in
Hacktoberfest. Maintainers of the repository can add the "hacktoberfest"
topic to their repository if they wish to participate. Alternatively, an
individual PR can be opted-in with a maintainer adding the
"hacktoberfest-accepted" label to the PR.
On Mon 5 Oct, 2020, 11:05 PM Atyant Yadav, notifications@github.com wrote:

Closed #214 https://github.com/atyant-yadav/Hactoberfest2020/issues/214.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/atyant-yadav/Hactoberfest2020/issues/214#event-3841648931,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL5YMBD7Z6ATGSDHI7KTVYLSJH7UZANCNFSM4SDZWY3A
.

@itsrahulhere i've updated the "hactoberfest" tag and it might take some time to get accepted as a participating repo, and to reflect changes.
I hope it helps :)

I got this mail pls read point number 3.
October is here, and so is Hacktoberfest!
Before contributing to awesome open source projects this month, we have
some important updates to share with you.
After working closely with our friends at GitHub, we are happy to introduce
measures that are brand new to Hacktoberfest 2020.

Pull requests can be made in any participating GitHub-hosted
repositories/projects.

Maintainers can opt-in to participate by classifying their projects
with the hacktoberfest topic
https://pages.news.digitalocean.com/n/P000X2VE6I0EqL090aKDoc3.

Your pull requests will count toward your participation if they are
in a repository with the hacktoberfest topic and once they have been
merged, approved by a maintainer or labelled as hacktoberfest-accepted.

Additionally, any pull request with the hacktoberfest-accepted label,
submitted to any public GitHub repository, with or without the
hacktoberfest topic, will be considered valid for Hacktoberfest.

All valid pull requests prior to Oct 3 (when these rules were introduced)
will be honored and counted toward completion of Hacktoberfest.
Learn more
https://pages.news.digitalocean.com/n/qoDE0V2a6L0XL903I0Er00c about the
changes we've made that will affect your participation.
Remember, there are tons of resources available to help get you started on
contributing quality pull requests:

Learn how to create your first pull request
https://pages.news.digitalocean.com/n/P000X2VE6I0EsL090aMDoc3
Review this beginner’s checklist
https://pages.news.digitalocean.com/n/wIaDXLVE60000EoN20c3t09 for
Hacktoberfest
Check out good first issues
https://pages.news.digitalocean.com/n/O090ELcD0320XE6u0O0VoaI to
contribute to
Chat with other contributors
https://pages.news.digitalocean.com/n/l9IcP0006oaE0D3VL0X0v2E in
Discord to learn tips on completing the challenge

We appreciate everyone doing their part to make Hacktoberfest a more
welcoming and positive experience for the global community. Please help
spread the word far and wide to get more repositories to opt in and partake
in the program.
If you have any questions, feedback or suggestions, feel free to reach out
to hacktoberfest@digitalocean.com
https://pages.news.digitalocean.com/n/c0L03cEE06XI2oVDQ0aw900.
Happy hacking,
Team DigitalOcean
On Mon 5 Oct, 2020, 11:13 PM Atyant Yadav, notifications@github.com wrote:

@itsrahulhere https://github.com/itsrahulhere i've updated the
"hactoberfest" tag and it might take some time to get accepted as a
participating repo, and to reflect changes.
I hope it helps :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/atyant-yadav/Hactoberfest2020/issues/214#issuecomment-703784238,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL5YMBG4S6LEVZ64SRMQZGDSJIAUNANCNFSM4SDZWY3A
.

Additionally, any pull request with the hacktoberfest-accepted label,
submitted to any public GitHub repository, with or without the
hacktoberfest topic, will be considered valid for Hacktoberfest.

@itsrahulhere
see this if you are worried too much.

The hactoberfest-accepted also requires the k in it.
Pls check
Thanks

authors: PriyavKaneria atyant-yadav itsrahulhere