I encountered a build failure on Windows that only happens with PYAPP_PROJECT_PATH.
I wanted to check out pyapp to see if it's usable in my day job, so I tried it on one of my hobby projects.
What works:
Setting up the build via PYAPP_PROJECT_NAME=autodigipick and PYAPP_PROJECT_VERSION=1.1.1
It grabs the files from PyPI and executes without problem.
What doesn't work:
Downloading the whl directly from PyPI into the pyapp project root to see how it handles proprietary projects that aren't on any index.
Setting PYAPP_PROJECT_PATH=autodigipick-1.1.1-py3-none-any.whl and running cargo build --release leads to the build failure below [1].
The panic message looks suspicious, almost as if the last character in name given to normalize_project_name() contains a carriage return character.
From what I can gather from the stacktrace, it looks like pyapp is trying read the name from the METADATA file contained in the whl. Since autodigipick was built on Windows, the METADATA file created during the build process has CRLF line endings.
The Regex in set_project_from_metadata() includes the \r in the capture and causes the Regex in normalize_project_name() to not match and subsequently panic.
If my deduction is correct, this is less a build failure on Windows, but a build failure with whl files built on Windows. But I'll keep the issue title vague for now since I'm not deep enough in this project to accurately deduct the root cause.
[1] Console output:
D:\git\pyapp>cargo build --release
Compiling pyapp v0.15.0 (D:\git\pyapp)
error: failed to run custom build command for `pyapp v0.15.0 (D:\git\pyapp)`
Caused by:
process didn't exit successfully: `D:\git\pyapp\target\release\build\pyapp-9c9a7185155e1e53\build-script-build` (exit code: 101)
--- stdout
cargo:rustc-env=PYAPP_PROJECT_DEPENDENCY_FILE=
cargo:rustc-env=PYAPP__PROJECT_DEPENDENCY_FILE_NAME=
--- stderr
thread 'main' panicked at build.rs:259:9:
`; must only contain ASCII letters/digits, underscores, hyphens, and periods, and must begin and end with ASCII letters/digits.
stack backtrace:
0: 0x7ff65ae66e32 - std::sys_common::backtrace::_print::impl$0::fmt
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\sys_common\backtrace.rs:44
1: 0x7ff65ae8118d - core::fmt::rt::Argument::fmt
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\core\src\fmt\rt.rs:142
2: 0x7ff65ae8118d - core::fmt::write
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\core\src\fmt\mod.rs:1120
3: 0x7ff65ae63301 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\io\mod.rs:1810
4: 0x7ff65ae66c5a - std::sys_common::backtrace::_print
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\sys_common\backtrace.rs:47
5: 0x7ff65ae66c5a - std::sys_common::backtrace::print
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\sys_common\backtrace.rs:34
6: 0x7ff65ae68ea9 - std::panicking::default_hook::closure$1
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:272
7: 0x7ff65ae68b65 - std::panicking::default_hook
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:292
8: 0x7ff65ae693d4 - std::panicking::rust_panic_with_hook
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:779
9: 0x7ff65ae692a9 - std::panicking::begin_panic_handler::closure$0
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:657
10: 0x7ff65ae674d9 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\sys_common\backtrace.rs:171
11: 0x7ff65ae68f72 - std::panicking::begin_panic_handler
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:645
12: 0x7ff65af77b27 - core::panicking::panic_fmt
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\core\src\panicking.rs:72
13: 0x7ff65a66e42a - build_script_build::normalize_project_name
at D:\git\pyapp\build.rs:259
14: 0x7ff65a66fac2 - build_script_build::set_project_from_metadata
at D:\git\pyapp\build.rs:378
15: 0x7ff65a670c8b - build_script_build::set_project
at D:\git\pyapp\build.rs:443
16: 0x7ff65a675d99 - build_script_build::main
at D:\git\pyapp\build.rs:931
17: 0x7ff65a67710b - core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\ops\function.rs:250
18: 0x7ff65a67b02e - core::hint::black_box
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\hint.rs:286
19: 0x7ff65a67b02e - std::sys_common::backtrace::__rust_begin_short_backtrace<void (*)(),tuple$<> >
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\std\src\sys_common\backtrace.rs:155
20: 0x7ff65a67b1f1 - std::rt::lang_start::closure$0<tuple$<> >
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\std\src\rt.rs:166
21: 0x7ff65ae5ec72 - std::rt::lang_start_internal::closure$2
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\rt.rs:148
22: 0x7ff65ae5ec72 - std::panicking::try::do_call
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:552
23: 0x7ff65ae5ec72 - std::panicking::try
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:516
24: 0x7ff65ae5ec72 - std::panic::catch_unwind
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panic.rs:142
25: 0x7ff65ae5ec72 - std::rt::lang_start_internal
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\rt.rs:148
26: 0x7ff65a67b1ca - std::rt::lang_start<tuple$<> >
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\std\src\rt.rs:165
27: 0x7ff65a675e09 - main
28: 0x7ff65af5b650 - invoke_main
at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
29: 0x7ff65af5b650 - __scrt_common_main_seh
at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
30: 0x7ffabe437614 - BaseThreadInitThunk
31: 0x7ffabf0626a1 - RtlUserThreadStart
I encountered a build failure on Windows that only happens with PYAPP_PROJECT_PATH.
I wanted to check out pyapp to see if it's usable in my day job, so I tried it on one of my hobby projects.
What works: Setting up the build via
PYAPP_PROJECT_NAME=autodigipick
andPYAPP_PROJECT_VERSION=1.1.1
It grabs the files from PyPI and executes without problem.What doesn't work: Downloading the whl directly from PyPI into the pyapp project root to see how it handles proprietary projects that aren't on any index. Setting
PYAPP_PROJECT_PATH=autodigipick-1.1.1-py3-none-any.whl
and runningcargo build --release
leads to the build failure below [1].The panic message looks suspicious, almost as if the last character in
name
given tonormalize_project_name()
contains a carriage return character.From what I can gather from the stacktrace, it looks like pyapp is trying read the name from the METADATA file contained in the whl. Since autodigipick was built on Windows, the METADATA file created during the build process has CRLF line endings. The Regex in
set_project_from_metadata()
includes the \r in the capture and causes the Regex innormalize_project_name()
to not match and subsequently panic.If my deduction is correct, this is less a build failure on Windows, but a build failure with whl files built on Windows. But I'll keep the issue title vague for now since I'm not deep enough in this project to accurately deduct the root cause.
[1] Console output: