mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-28 23:20:10 +08:00
Hacker
GitHub
commit
a1b97b9bed
@ -3,14 +3,16 @@
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-13192-1.html)
|
||||
|
||||
运行 Linux 服务器的 4 个开源工具
|
||||
4 个打造多媒体和共享服务器的开源工具
|
||||
======
|
||||
通过 Linux，你可以将任何设备变成服务器，以共享数据、媒体文件，以及其他资源。
|
||||
![A rack of servers, blue background][1]
|
||||
|
||||
> 通过 Linux，你可以将任何设备变成服务器，以共享数据、媒体文件，以及其他资源。
|
||||
|
||||
|
||||
|
||||
在 2021 年，人们喜欢 Linux 的理由比以往任何时候都多。在这个系列中，我将分享 21 个使用 Linux 的不同理由。这里有四个开源工具，可以将任何设备变成 Linux 服务器。
|
||||
|
||||
@ -20,15 +22,13 @@
|
||||
|
||||
### Samba
|
||||
|
||||
[Samba 项目][2]是 Linux 和 Unix 的 Windows 互操作程序套件。尽管它是大多数用户从未与之交互的底层代码，但它的重要性却不容小觑。从历史上看，早在微软争相消灭 Linux 和开源的时候，它就是最大最重要的目标。时代变了，微软已经与 Samba 团队会面以提供支持（至少目前是这样），在这一切中，该项目继续确保 Linux 和 Windows 计算机可以轻松地在同一网络上共存。换句话说，无论你使用什么平台，Samba 都可以让你可以轻松地在本地网络上共享文件。
|
||||
[Samba 项目][2] 是 Linux 和 Unix 的 Windows 互操作程序套件。尽管它是大多数用户从未与之交互的底层代码，但它的重要性却不容小觑。从历史上看，早在微软争相消灭 Linux 和开源的时候，它就是最大最重要的目标。时代变了，微软已经与 Samba 团队会面以提供支持（至少目前是这样），在这一切中，该项目继续确保 Linux 和 Windows 计算机可以轻松地在同一网络上共存。换句话说，无论你使用什么平台，Samba 都可以让你可以轻松地在本地网络上共享文件。
|
||||
|
||||
在 [KDE Plasma][3] 桌面上，你可以右键点击自己的任何目录，选择**属性**。在**属性**对话框中，点击**共享**选项卡，并启用**与 Samba 共享 （Microsoft Windows）**。
|
||||
在 [KDE Plasma][3] 桌面上，你可以右键点击自己的任何目录，选择**属性**。在**属性**对话框中，点击**共享**选项卡，并启用**与 Samba 共享（Microsoft Windows）**。
|
||||
|
||||
![Samba][4]
|
||||
|
||||
（Seth Kenlon, [CC BY-SA 4.0][5]）
|
||||
|
||||
就这样，你已经为本地网络上的用户打开了一个只读访问的目录。也就是说，当你在家的时候，你家同一个 WiFi 网络上的任何人都可以访问该文件夹，如果你在工作，工作场所网络上的任何人都可以访问该文件夹。当然，要访问它，其他用户需要知道在哪里可以找到它。通往计算机的路径可以用 [IP 地址][6]表示，也可以根据你的网络配置，用主机名表示。
|
||||
就这样，你已经为本地网络上的用户打开了一个只读访问的目录。也就是说，当你在家的时候，你家同一个 WiFi 网络上的任何人都可以访问该文件夹，如果你在工作，工作场所网络上的任何人都可以访问该文件夹。当然，要访问它，其他用户需要知道在哪里可以找到它。通往计算机的路径可以用 [IP 地址][6] 表示，也可以根据你的网络配置，用主机名表示。
|
||||
|
||||
### Snapdrop
|
||||
|
||||
@ -36,44 +36,37 @@
|
||||
|
||||
![Snapdrop][8]
|
||||
|
||||
（Seth Kenlon, [CC BY-SA 4.0][5]）
|
||||
|
||||
一旦两个或更多的客户端连接了同一个 Snapdrop 服务，用户就可以通过本地网络来回交换文件和聊天信息。传输的速度很快，而且你的数据也保持在本地。
|
||||
|
||||
### VLC
|
||||
|
||||
流媒体服务比以往任何时候都更常见，但我在音乐和电影方面有非常规的口味，所以典型的服务似乎很少有我想要的东西。幸运的是，通过连接到媒体驱动器，我可以很容易地将自己的内容从我的电脑上传送到我的房子各个角落。例如，当我想在电脑显示器以外的屏幕上观看一部电影时，我可以在我的网络上串流电影文件，并通过任何可以接收 HTTP 的应用来播放它，无论该应用是在我的电视、游戏机还是手机上。
|
||||
|
||||
[VLC][9] 可以轻松设置流媒体。事实上，它是**媒体**菜单中的一个选项，或者你可以按下键盘 **Ctrl**+**S**。将一个文件或一组文件添加到你的流媒体队列中，然后点击 **Stream** 按钮。
|
||||
[VLC][9] 可以轻松设置流媒体。事实上，它是**媒体**菜单中的一个选项，或者你可以按下键盘 `Ctrl+S`。将一个文件或一组文件添加到你的流媒体队列中，然后点击 **Stream** 按钮。
|
||||
|
||||
![VLC][10]
|
||||
|
||||
（Seth Kenlon, [CC BY-SA 4.0][5]）
|
||||
|
||||
VLC 通过配置向导来帮助你决定流媒体数据时使用什么协议。我倾向于使用 HTTP，因为它通常在任何设备上可用。当 VLC 开始播放文件时， 请进入播放文件计算机的 IP 或主机名以及给它分配的端口 （当使用 HTTP，默认是 8080）, 然后坐下来享受。
|
||||
VLC 通过配置向导来帮助你决定流媒体数据时使用什么协议。我倾向于使用 HTTP，因为它通常在任何设备上可用。当 VLC 开始播放文件时，请进入播放文件计算机的 IP 或主机名以及给它分配的端口 （当使用 HTTP 时，默认是 8080）, 然后坐下来享受。
|
||||
|
||||
### PulseAudio
|
||||
|
||||
我最喜欢的现代 Linux 功能之一是 [PulseAudio][11]。Pulse 为 Linux 上的音频实现了惊人的灵活性，包括可自动发现的本地网络流媒体。这个功能对我来说的好处是，我可以在办公室的工作站上播放播客和技术会议视频，并通过手机串流音频。无论我走进厨房、休息室还是后院最远的地方，我都能获得完美的音频。此功能在 PulseAudio 之前很久就存在，但是 Pulse 使它像单击按钮一样容易。
|
||||
|
||||
需要进行一些设置。首先，你必须确保安装 PulseAudio preferences（**paprefs**）包，以便在 PulseAudio 配置中启用网络音频。
|
||||
需要进行一些设置。首先，你必须确保安装 PulseAudio 设置包（**paprefs**），以便在 PulseAudio 配置中启用网络音频。
|
||||
|
||||
![PulseAudio][12]
|
||||
|
||||
（Seth Kenlon, [CC BY-SA 4.0][5]）
|
||||
|
||||
在 **paprefs** 中，启用网络访问你的本地声音设备，可能不需要认证（假设你信任本地网络上的其他人），并启用你的计算机作为 **Multicast/RTP 发送者**。我通常只选择串流通过我的扬声器播放的任何音频，但你可以在 Pulse 输出选项卡中创建一个单独的音频设备，这样你就可以准确地选择串流的内容。你在这里有三个选项：
|
||||
|
||||
* 串流任何在扬声器上播放的音频
|
||||
* 串流所有输出的声音
|
||||
* 只将音频直接串流到多播设备（按需）。
|
||||
|
||||
|
||||
一旦启用，你的声音就会串流道网络中，并可被其他本地 Linux 设备接收。这是简单和动态的音频共享。
|
||||
一旦启用，你的声音就会串流到网络中，并可被其他本地 Linux 设备接收。这是简单和动态的音频共享。
|
||||
|
||||
### 分享的不仅仅是代码
|
||||
|
||||
Linux 是关于共享的。它在服务器领域很有名，因为它很擅长_服务_。无论是提供音频流、视频流、文件，还是出色的用户体验，每一台 Linux 电脑都是一台出色的 Linux 服务器。
|
||||
Linux 是共享的。它在服务器领域很有名，因为它很擅长*服务*。无论是提供音频流、视频流、文件，还是出色的用户体验，每一台 Linux 电脑都是一台出色的 Linux 服务器。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -82,7 +75,7 @@ via: https://opensource.com/article/21/3/linux-server
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,318 +0,0 @@
|
||||
[#]: subject: (Learn to debug code with the GNU Debugger)
|
||||
[#]: via: (https://opensource.com/article/21/3/debug-code-gdb)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
Learn to debug code with the GNU Debugger
|
||||
======
|
||||
Troubleshoot your code with the GNU Debugger. Download our new cheat
|
||||
sheet.
|
||||
![magnifying glass on computer screen, finding a bug in the code][1]
|
||||
|
||||
The GNU Debugger, more commonly known by its command, `gdb`, is an interactive console to help you step through source code, analyze what gets executed, and essentially reverse-engineer what's going wrong in a buggy application.
|
||||
|
||||
The trouble with troubleshooting is that it's complex. [GNU Debugger][2] isn't exactly a complex application, but it can be overwhelming if you don't know where to start or even when and why you might need to turn to GDB to do your troubleshooting. If you've been using print, echo, or [printf statements][3] to debug your code, but you're beginning to suspect there may be something more powerful, then this tutorial is for you.
|
||||
|
||||
### Code is buggy
|
||||
|
||||
To get started with GDB, you need some code. Here's a sample application written in C++ (it's OK if you don't typically write in C++, the principles are the same across all languages), derived from one of the examples in the [guessing game series][4] here on Opensource.com:
|
||||
|
||||
|
||||
```
|
||||
#include <iostream>
|
||||
#include <stdlib.h> //srand
|
||||
#include <stdio.h> //printf
|
||||
|
||||
using namespace std;
|
||||
|
||||
int main () {
|
||||
|
||||
srand (time(NULL));
|
||||
int alpha = rand() % 8;
|
||||
cout << "Hello world." << endl;
|
||||
int beta = 2;
|
||||
|
||||
printf("alpha is set to is %s\n", alpha);
|
||||
printf("kiwi is set to is %s\n", beta);
|
||||
|
||||
return 0;
|
||||
} // main
|
||||
```
|
||||
|
||||
There's a bug in this code sample, but it does compile (at least as of GCC 5). If you're familiar with C++, you may already see it, but it's a simple problem that can help new GDB users understand the debugging process. Compile it and run it to see the error:
|
||||
|
||||
|
||||
```
|
||||
$ g++ -o buggy example.cpp
|
||||
$ ./buggy
|
||||
Hello world.
|
||||
Segmentation fault
|
||||
```
|
||||
|
||||
### Troubleshooting a segmentation fault
|
||||
|
||||
From this output, you can surmise that the variable `alpha` was set correctly because otherwise, you wouldn't expect the line of code that came _after_ it. That's not always true, of course, but it's a good working theory, and it's essentially the same conclusion you'd likely come to if you were using `printf` as a log and debugger. From here, you can assume that the bug lies in _some line_ after the one that printed successfully. However, it's not clear whether the bug is in the very next line or several lines later.
|
||||
|
||||
GNU Debugger is an interactive troubleshooter, so you can use the `gdb` command to run buggy code. For best results, you should recompile your buggy application from source code with _debug symbols_ included. First, take a look at what information GDB can provide without recompiling:
|
||||
|
||||
|
||||
```
|
||||
$ gdb ./buggy
|
||||
Reading symbols from ./buggy...done.
|
||||
(gdb) start
|
||||
Temporary breakpoint 1 at 0x400a44
|
||||
Starting program: /home/seth/demo/buggy
|
||||
|
||||
Temporary breakpoint 1, 0x0000000000400a44 in main ()
|
||||
(gdb)
|
||||
```
|
||||
|
||||
When you start GDB with a binary executable as the argument, GDB loads the application and then waits for your instructions. Because this is the first time you're running GDB on this executable, it makes sense to try to repeat the error in hopes that GDB can provide further insight. GDB's command to launch the application it has loaded is, intuitively enough, `start`. By default, there's a _breakpoint_ built into GDB so that when it encounters the `main` function of your application, it pauses execution. To allow GDB to proceed, use the command `continue`:
|
||||
|
||||
|
||||
```
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
Hello world.
|
||||
|
||||
Program received signal SIGSEGV, Segmentation fault.
|
||||
0x00007ffff71c0c0b in vfprintf () from /lib64/libc.so.6
|
||||
(gdb)
|
||||
```
|
||||
|
||||
No surprises here: the application crashed shortly after printing "Hello world," but GDB can provide the function call that was happening when the crash occurred. This could potentially be all you need to find the bug that's causing the crash, but to get a better idea of GDB's features and the general debugging process, imagine that the problem hasn't become clear yet, and you want to dig even deeper into what's happening with this code.
|
||||
|
||||
### Compiling code with debug symbols
|
||||
|
||||
To get the most out of GDB, you need debug symbols compiled into your executable. You can generate this with the `-g` option in GCC:
|
||||
|
||||
|
||||
```
|
||||
$ g++ -o debuggy example.cpp
|
||||
$ ./debuggy
|
||||
Hello world.
|
||||
Segmentation fault
|
||||
```
|
||||
|
||||
Compiling debug symbols into an executable results in a much larger file, so they're usually not distributed with the added convenience. However, if you're debugging open source code, it makes sense to recompile with debug symbols for testing:
|
||||
|
||||
|
||||
```
|
||||
$ ls -l *buggy* *cpp
|
||||
-rw-r--r-- 310 Feb 19 08:30 debug.cpp
|
||||
-rwxr-xr-x 11624 Feb 19 10:27 buggy*
|
||||
-rwxr-xr-x 22952 Feb 19 10:53 debuggy*
|
||||
```
|
||||
|
||||
### Debugging with GDB
|
||||
|
||||
Launch GDB with your new executable (`debuggy`, in this example) loaded:
|
||||
|
||||
|
||||
```
|
||||
$ gdb ./debuggy
|
||||
Reading symbols from ./debuggy...done.
|
||||
(gdb) start
|
||||
Temporary breakpoint 1 at 0x400a44
|
||||
Starting program: /home/seth/demo/debuggy
|
||||
|
||||
Temporary breakpoint 1, 0x0000000000400a44 in main ()
|
||||
(gdb)
|
||||
```
|
||||
|
||||
As before, use the `start` command to proceed:
|
||||
|
||||
|
||||
```
|
||||
(gdb) start
|
||||
Temporary breakpoint 1 at 0x400a48: file debug.cpp, line 9.
|
||||
Starting program: /home/sek/demo/debuggy
|
||||
|
||||
Temporary breakpoint 1, main () at debug.cpp:9
|
||||
9 srand (time(NULL));
|
||||
(gdb)
|
||||
```
|
||||
|
||||
This time, the automatic `main` breakpoint can specify what line number GDB paused on and what code the line contains. You could resume normal operation with `continue` but you already know that the application crashes before completion, so instead, you can step through your code line-by-line using the `next` keyword:
|
||||
|
||||
|
||||
```
|
||||
(gdb) next
|
||||
10 int alpha = rand() % 8;
|
||||
(gdb) next
|
||||
11 cout << "Hello world." << endl;
|
||||
(gdb) next
|
||||
Hello world.
|
||||
12 int beta = 2;
|
||||
(gdb) next
|
||||
14 printf("alpha is set to is %s\n", alpha);
|
||||
(gdb) next
|
||||
|
||||
Program received signal SIGSEGV, Segmentation fault.
|
||||
0x00007ffff71c0c0b in vfprintf () from /lib64/libc.so.6
|
||||
(gdb)
|
||||
```
|
||||
|
||||
From this process, you can confirm that the crash didn't happen when the `beta` variable was being set but when the `printf` line was executed. The bug has been exposed several times in this article (spoiler: the wrong data type is being provided to `printf`), but assume for a moment that the solution remains unclear and that further investigation is required.
|
||||
|
||||
### Setting breakpoints
|
||||
|
||||
Once your code is loaded into GDB, you can ask GDB about the data that the code has produced so far. To try some data introspection, restart your application by issuing the `start` command again and then proceed to line 11. An easy way to get to 11 quickly is to set a breakpoint that looks for a specific line number:
|
||||
|
||||
|
||||
```
|
||||
(gdb) start
|
||||
The program being debugged has been started already.
|
||||
Start it from the beginning? (y or n) y
|
||||
Temporary breakpoint 2 at 0x400a48: file debug.cpp, line 9.
|
||||
Starting program: /home/sek/demo/debuggy
|
||||
|
||||
Temporary breakpoint 2, main () at debug.cpp:9
|
||||
9 srand (time(NULL));
|
||||
(gdb) break 11
|
||||
Breakpoint 3 at 0x400a74: file debug.cpp, line 11.
|
||||
```
|
||||
|
||||
With the breakpoint established, continue the execution with `continue`:
|
||||
|
||||
|
||||
```
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
|
||||
Breakpoint 3, main () at debug.cpp:11
|
||||
11 cout << "Hello world." << endl;
|
||||
(gdb)
|
||||
```
|
||||
|
||||
You're now paused at line 11, just after the `alpha` variable has been set, and just before `beta` gets set.
|
||||
|
||||
### Doing variable introspection with GDB
|
||||
|
||||
To see the value of a variable, use the `print` command. The value of `alpha` is random in this example code, so your actual results may vary from mine:
|
||||
|
||||
|
||||
```
|
||||
(gdb) print alpha
|
||||
$1 = 3
|
||||
(gdb)
|
||||
```
|
||||
|
||||
Of course, you can't see the value of a variable that has not yet been established:
|
||||
|
||||
|
||||
```
|
||||
(gdb) print beta
|
||||
$2 = 0
|
||||
```
|
||||
|
||||
### Using flow control
|
||||
|
||||
To proceed, you could step through the lines of code to get to the point where `beta` is set to a value:
|
||||
|
||||
|
||||
```
|
||||
(gdb) next
|
||||
Hello world.
|
||||
12 int beta = 2;
|
||||
(gdb) next
|
||||
14 printf("alpha is set to is %s\n", alpha);
|
||||
(gdb) print beta
|
||||
$3 = 2
|
||||
```
|
||||
|
||||
Alternatively, you could set a watchpoint. A watchpoint, like a breakpoint, is a way to control the flow of how GDB executes the code. In this case, you know that the `beta` variable should be set to `2`, so you could set a watchpoint to alert you when the value of `beta` changes:
|
||||
|
||||
|
||||
```
|
||||
(gdb) watch beta > 0
|
||||
Hardware watchpoint 5: beta > 0
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
|
||||
Breakpoint 3, main () at debug.cpp:11
|
||||
11 cout << "Hello world." << endl;
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
Hello world.
|
||||
|
||||
Hardware watchpoint 5: beta > 0
|
||||
|
||||
Old value = false
|
||||
New value = true
|
||||
main () at debug.cpp:14
|
||||
14 printf("alpha is set to is %s\n", alpha);
|
||||
(gdb)
|
||||
```
|
||||
|
||||
You can step through the code execution manually with `next`, or you can control how the code executes with breakpoints, watchpoints, and catchpoints.
|
||||
|
||||
### Analyzing data with GDB
|
||||
|
||||
You can see data in different formats. For instance, to see the value of `beta` as an octal value:
|
||||
|
||||
|
||||
```
|
||||
(gdb) print /o beta
|
||||
$4 = 02
|
||||
```
|
||||
|
||||
To see its address in memory:
|
||||
|
||||
|
||||
```
|
||||
(gdb) print /o beta
|
||||
$5 = 0x2
|
||||
```
|
||||
|
||||
You can also see the data type of a variable:
|
||||
|
||||
|
||||
```
|
||||
(gdb) whatis beta
|
||||
type = int
|
||||
```
|
||||
|
||||
### Solving bugs with GDB
|
||||
|
||||
This kind of introspection better informs you about not only what code is getting executed but how it's getting executed. In this example, the `whatis` command on a variable gives you a clue that your `alpha` and `beta` variables are integers, which might jog your memory about `printf` syntax, making you realize that instead of `%s` in your `printf` statements, you must use the `%d` designator. Making that change causes the application to run as expected, with no more obvious bugs present.
|
||||
|
||||
It's especially frustrating when code compiles but then reveals that there are bugs present, but that's how the trickiest of bugs work. If they were easy to catch, they wouldn't be bugs. Using GDB is one way to hunt them down and eliminate them.
|
||||
|
||||
### Download our cheatsheet
|
||||
|
||||
It's a fact of life, in even the most basic forms of programming, that code has bugs. Not all bugs are so crippling that they stop an application from running (or even from compiling), and not all bugs are caused by incorrect code. Sometimes bugs happen intermittently based on an unexpected combination of choices made by a particularly creative user. Sometimes programmers inherit bugs from the libraries they use in their own code. Whatever the cause, bugs are basically everywhere, and it's part of the programmer's job to find and neutralize them.
|
||||
|
||||
GNU Debugger is a useful tool in finding bugs. There's a lot more you can do with it than I demonstrated in this article. You can read about its many functions with the GNU Info reader:
|
||||
|
||||
|
||||
```
|
||||
`$ info gdb`
|
||||
```
|
||||
|
||||
Whether you're just learning GDB or you're a pro at it, it never hurts to have a reminder of what commands are available to you and what the syntax for those commands are.
|
||||
|
||||
### [Download our cheatsheet for GDB today.][5]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/21/3/debug-code-gdb
|
||||
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/mistake_bug_fix_find_error.png?itok=PZaz3dga (magnifying glass on computer screen, finding a bug in the code)
|
||||
[2]: https://www.gnu.org/software/gdb/
|
||||
[3]: https://opensource.com/article/20/8/printf
|
||||
[4]: https://opensource.com/article/20/12/learn-c-game
|
||||
[5]: https://opensource.com/downloads/gnu-debugger-cheat-sheet
|
||||
@ -1,206 +0,0 @@
|
||||
[#]: subject: (How to use Poetry to manage your Python projects on Fedora)
|
||||
[#]: via: (https://fedoramagazine.org/how-to-use-poetry-to-manage-your-python-projects-on-fedora/)
|
||||
[#]: author: (Kader Miyanyedi https://fedoramagazine.org/author/moonkat/)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
How to use Poetry to manage your Python projects on Fedora
|
||||
======
|
||||
|
||||
![Python & Poetry on Fedora][1]
|
||||
|
||||
Python developers often create a new virtual environment to separate project dependencies and then manage them with tools such as _pip, pipenv, etc._ Poetry is a tool for simplifying dependency management and packaging in Python. This post will show you how to use Poetry to manage your Python projects on Fedora.
|
||||
|
||||
Unlike other tools, Poetry uses only a single configuration file for dependency management, packaging, and publishing. This eliminates the need for different files such as _Pipfile, MANIFEST.in, setup.py_, etc. It is also faster than **using multiple tools.
|
||||
|
||||
Detailed below is a brief overview of commands used when getting started with Poetry.
|
||||
|
||||
### **Installing Poetry on Fedora**
|
||||
|
||||
If you already use Fedora 32 or above, you can install Poetry directly from the command line using this command:
|
||||
|
||||
```
|
||||
$ sudo dnf install poetry
|
||||
```
|
||||
|
||||
```
|
||||
Editor note: on Fedora Silverblue or CoreOs Python 3.9.2 is part of the core commit, you would layer Poetry with '
|
||||
```
|
||||
|
||||
rpm-ostree install poetry
|
||||
|
||||
```
|
||||
'
|
||||
```
|
||||
|
||||
### Initialize a project
|
||||
|
||||
Create a new project using the _new_ command.
|
||||
|
||||
```
|
||||
$ poetry new poetry-project
|
||||
```
|
||||
|
||||
The structure of a project created with Poetry looks like this:
|
||||
|
||||
```
|
||||
├── poetry_project
|
||||
│ └── init.py
|
||||
├── pyproject.toml
|
||||
├── README.rst
|
||||
└── tests
|
||||
├── init.py
|
||||
└── test_poetry_project.py
|
||||
```
|
||||
|
||||
Poetry uses _pyproject.toml_ to manage the dependencies of your project. Initially, this file will look similar to this:
|
||||
|
||||
```
|
||||
[tool.poetry]
|
||||
name = "poetry-project"
|
||||
version = "0.1.0"
|
||||
description = ""
|
||||
authors = ["Kadermiyanyedi <kadermiyanyedi@hotmail.com>"]
|
||||
|
||||
[tool.poetry.dependencies]
|
||||
python = "^3.9"
|
||||
|
||||
[tool.poetry.dev-dependencies]
|
||||
pytest = "^5.2"
|
||||
|
||||
[build-system]
|
||||
requires = ["poetry>=0.12"]
|
||||
build-backend = "poetry.masonry.api"
|
||||
```
|
||||
|
||||
This file contains 4 sections:
|
||||
|
||||
* The first section contains information describing the project such as project name, project version, etc.
|
||||
* The second section contains project dependencies. These dependencies are necessary to build the project.
|
||||
* The third section contains development dependencies.
|
||||
* The fourth section describes a building system as in [PEP 517][2]
|
||||
|
||||
|
||||
|
||||
If you already have a project, or create your own project folder, and you want to use poetry, run the _init_ command within your project.
|
||||
|
||||
```
|
||||
$ poetry init
|
||||
```
|
||||
|
||||
After this command, you will see an interactive shell to configure your project.
|
||||
|
||||
### Create a virtual environment
|
||||
|
||||
If you want to create a virtual environment or activate an existing virtual environment, use the command below:
|
||||
|
||||
```
|
||||
$ poetry shell
|
||||
```
|
||||
|
||||
Poetry creates the virtual environment in the _/home/username/.cache/pypoetry_ project by default. You can change the default path by editing the poetry config. Use the command below to see the config list:
|
||||
|
||||
```
|
||||
$ poetry config --list
|
||||
|
||||
cache-dir = "/home/username/.cache/pypoetry"
|
||||
virtualenvs.create = true
|
||||
virtualenvs.in-project = true
|
||||
virtualenvs.path = "{cache-dir}/virtualenvs"
|
||||
```
|
||||
|
||||
Change the _virtualenvs.in-project_ configuration variable to create a virtual environment within your project directory. The Poetry command is:
|
||||
|
||||
```
|
||||
$ poetry config virtualenv.in-project true
|
||||
```
|
||||
|
||||
### Add dependencies
|
||||
|
||||
Install a dependency for the project with the _poetry add_ command.
|
||||
|
||||
```
|
||||
$ poetry add django
|
||||
```
|
||||
|
||||
You can identify any dependencies that you use only for the development environment using the _add_ command with the _–dev_ option.
|
||||
|
||||
```
|
||||
$ poetry add black --dev
|
||||
```
|
||||
|
||||
The **add** command creates a _poetry.lock file_ that is used to track package versions. If the _poetry.lock_ file doesn’t exist, the latest versions of all dependencies in _pyproject.toml_ are installed. If _poetry.lock_ does exist, Poetry uses the exact versions listed in the file to ensure that the package versions are consistent for everyone working on your project.
|
||||
|
||||
Use the poetry _install_ command to install all dependencies in your current project.
|
||||
|
||||
```
|
||||
$ poetry install
|
||||
```
|
||||
|
||||
Prevent development dependencies from being installed by using the _no-dev_ option.
|
||||
|
||||
```
|
||||
$ poetry install --no-dev
|
||||
```
|
||||
|
||||
### List packages
|
||||
|
||||
The _show_ command lists all of the available packages. The _tree_ option will list packages as a tree.
|
||||
|
||||
```
|
||||
$ poetry show --tree
|
||||
|
||||
django 3.1.7 A high-level Python Web framework that encourages rapid development and clean, pragmatic design.
|
||||
├── asgiref >=3.2.10,<4
|
||||
├── pytz *
|
||||
└── sqlparse >=0.2.2
|
||||
```
|
||||
|
||||
Include the package name to list details of a specific package.
|
||||
|
||||
```
|
||||
$ poetry show requests
|
||||
|
||||
name : requests
|
||||
version : 2.25.1
|
||||
description : Python HTTP for Humans.
|
||||
|
||||
dependencies
|
||||
- certifi >=2017.4.17
|
||||
- chardet >=3.0.2,<5
|
||||
- idna >=2.5,<3
|
||||
- urllib3 >=1.21.1,<1.27
|
||||
```
|
||||
|
||||
Finally, if you want to learn the latest version of the packages, you can pass the _latest_ option.
|
||||
|
||||
```
|
||||
$ poetry show --latest
|
||||
|
||||
idna 2.10 3.1 Internationalized Domain Names in Applications
|
||||
asgiref 3.3.1 3.3.1 ASGI specs, helper code, and adapters
|
||||
```
|
||||
|
||||
### Further information
|
||||
|
||||
More details on Poetry are available in the [documentation][3].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/how-to-use-poetry-to-manage-your-python-projects-on-fedora/
|
||||
|
||||
作者：[Kader Miyanyedi][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://fedoramagazine.org/author/moonkat/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoramagazine.org/wp-content/uploads/2021/03/Poetry_Python-816x345.jpg
|
||||
[2]: https://www.python.org/dev/peps/pep-0517/
|
||||
[3]: https://python-poetry.org/docs/
|
||||
@ -2,7 +2,7 @@
|
||||
[#]: via: (https://itsfoss.com/gimagereader-ocr/)
|
||||
[#]: author: (Ankush Das https://itsfoss.com/author/ankush/)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -0,0 +1,301 @@
|
||||
[#]: subject: (Learn to debug code with the GNU Debugger)
|
||||
[#]: via: (https://opensource.com/article/21/3/debug-code-gdb)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
学习使用 GDB 调试代码
|
||||
======
|
||||
|
||||
> 使用 GNU 调试器来解决你的代码问题。
|
||||
|
||||
![在电脑屏幕上放大镜，发现代码中的错误][1]
|
||||
|
||||
GNU 调试器常以它的命令 `gdb` 称呼它，它是一个交互式的控制台，可以帮助你浏览源代码、分析执行的内容，其本质上是对错误的应用程序中出现的问题进行逆向工程。
|
||||
|
||||
故障排除的麻烦在于它很复杂。[GNU 调试器][2] 并不是一个特别复杂的应用程序，但如果你不知道从哪里开始，甚至不知道何时和为何你可能需要求助于 GDB 来进行故障排除，那么它可能会让人不知所措。如果你一直使用 `print`、`echo` 或 [printf 语句][3]来调试你的代码，当你开始思考是不是还有更强大的东西时，那么本教程就是为你准备的。
|
||||
|
||||
### 有错误的代码
|
||||
|
||||
要开始使用 GDB，你需要一些代码。这里有一个用 C++ 写的示例应用程序（如果你一般不使用 C++ 编写程序也没关系，在所有语言中原理都是一样的），其来源于 [猜谜游戏系列][4] 中的一个例子。
|
||||
|
||||
```
|
||||
#include <iostream>
|
||||
#include <stdlib.h> //srand
|
||||
#include <stdio.h> //printf
|
||||
|
||||
using namespace std;
|
||||
|
||||
int main () {
|
||||
|
||||
srand (time(NULL));
|
||||
int alpha = rand() % 8;
|
||||
cout << "Hello world." << endl;
|
||||
int beta = 2;
|
||||
|
||||
printf("alpha is set to is %s\n", alpha);
|
||||
printf("kiwi is set to is %s\n", beta);
|
||||
|
||||
return 0;
|
||||
} // main
|
||||
```
|
||||
|
||||
这个代码示例中有一个 bug，但它确实可以编译（至少在 GCC 5 的时候）。如果你熟悉 C++，你可能已经看到了，但这是一个简单的问题，可以帮助新的 GDB 用户了解调试过程。编译并运行它就可以看到错误：
|
||||
|
||||
```
|
||||
$ g++ -o buggy example.cpp
|
||||
$ ./buggy
|
||||
Hello world.
|
||||
Segmentation fault
|
||||
```
|
||||
|
||||
### 排除段故障
|
||||
|
||||
从这个输出中，你可以推测变量 `alpha` 的设置是正确的，因为否则的话，你就不会看到它*后面*的那行代码执行。当然，这并不总是正确的，但这是一个很好的工作理论，如果你使用 `printf` 作为日志和调试器，基本上也会得出同样的结论。从这里，你可以假设 bug 在于成功打印的那一行之后的*某行*。然而，不清楚错误是在下一行还是在几行之后。
|
||||
|
||||
GNU 调试器是一个交互式的故障排除工具，所以你可以使用 `gdb` 命令来运行错误的代码。为了得到更好的结果，你应该从包含有*调试符号*的源代码中重新编译你的错误应用程序。首先，看看 GDB 在不重新编译的情况下能提供哪些信息：
|
||||
|
||||
```
|
||||
$ gdb ./buggy
|
||||
Reading symbols from ./buggy...done.
|
||||
(gdb) start
|
||||
Temporary breakpoint 1 at 0x400a44
|
||||
Starting program: /home/seth/demo/buggy
|
||||
|
||||
Temporary breakpoint 1, 0x0000000000400a44 in main ()
|
||||
(gdb)
|
||||
```
|
||||
|
||||
当你以一个二进制可执行文件作为参数启动 GDB 时，GDB 会加载该应用程序，然后等待你的指令。因为这是你第一次在这个可执行文件上运行 GDB，所以尝试重复这个错误是有意义的，希望 GDB 能够提供进一步的见解。很直观，GDB 用来启动它所加载的应用程序的命令就是 `start`。默认情况下，GDB 内置了一个*断点*，所以当它遇到你的应用程序的 `main` 函数时，它会暂停执行。要让 GDB 继续执行，使用命令 `continue`：
|
||||
|
||||
```
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
Hello world.
|
||||
|
||||
Program received signal SIGSEGV, Segmentation fault.
|
||||
0x00007ffff71c0c0b in vfprintf () from /lib64/libc.so.6
|
||||
(gdb)
|
||||
```
|
||||
|
||||
毫不意外：应用程序在打印 “Hello world” 后不久就崩溃了，但 GDB 可以提供崩溃发生时正在发生的函数调用。这有可能就足够你找到导致崩溃的 bug，但为了更好地了解 GDB 的功能和一般的调试过程，想象一下，如果问题还没有变得清晰，你想更深入地挖掘这段代码发生了什么。
|
||||
|
||||
### 用调试符号编译代码
|
||||
|
||||
要充分利用 GDB，你需要将调试符号编译到你的可执行文件中。你可以用 GCC 中的 `-g` 选项来生成这个符号：
|
||||
|
||||
```
|
||||
$ g++ -o debuggy example.cpp
|
||||
$ ./debuggy
|
||||
Hello world.
|
||||
Segmentation fault
|
||||
```
|
||||
|
||||
将调试符号编译到可执行文件中的结果是得到一个大得多的文件，所以通常不会分发它们，以增加便利性。然而，如果你正在调试开源代码，那么用调试符号重新编译测试是有意义的：
|
||||
|
||||
```
|
||||
$ ls -l *buggy* *cpp
|
||||
-rw-r--r-- 310 Feb 19 08:30 debug.cpp
|
||||
-rwxr-xr-x 11624 Feb 19 10:27 buggy*
|
||||
-rwxr-xr-x 22952 Feb 19 10:53 debuggy*
|
||||
```
|
||||
|
||||
### 用 GDB 调试
|
||||
|
||||
加载新的可执行文件（本例中为 `debuggy`）以启动 GDB：
|
||||
|
||||
```
|
||||
$ gdb ./debuggy
|
||||
Reading symbols from ./debuggy...done.
|
||||
(gdb) start
|
||||
Temporary breakpoint 1 at 0x400a44
|
||||
Starting program: /home/seth/demo/debuggy
|
||||
|
||||
Temporary breakpoint 1, 0x0000000000400a44 in main ()
|
||||
(gdb)
|
||||
```
|
||||
|
||||
如前所述，使用 `start` 命令进行：
|
||||
|
||||
```
|
||||
(gdb) start
|
||||
Temporary breakpoint 1 at 0x400a48: file debug.cpp, line 9.
|
||||
Starting program: /home/sek/demo/debuggy
|
||||
|
||||
Temporary breakpoint 1, main () at debug.cpp:9
|
||||
9 srand (time(NULL));
|
||||
(gdb)
|
||||
```
|
||||
|
||||
这一次，自动的 `main` 断点可以指明 GDB 暂停的行号和该行包含的代码。你可以用 `continue` 恢复正常操作，但你已经知道应用程序在完成之前就会崩溃，因此，你可以使用 `next` 关键字逐行步进检查你的代码：
|
||||
|
||||
```
|
||||
(gdb) next
|
||||
10 int alpha = rand() % 8;
|
||||
(gdb) next
|
||||
11 cout << "Hello world." << endl;
|
||||
(gdb) next
|
||||
Hello world.
|
||||
12 int beta = 2;
|
||||
(gdb) next
|
||||
14 printf("alpha is set to is %s\n", alpha);
|
||||
(gdb) next
|
||||
|
||||
Program received signal SIGSEGV, Segmentation fault.
|
||||
0x00007ffff71c0c0b in vfprintf () from /lib64/libc.so.6
|
||||
(gdb)
|
||||
```
|
||||
|
||||
从这个过程可以确认，崩溃不是发生在设置 `beta` 变量的时候，而是执行 `printf` 行的时候。这个 bug 在本文中已经暴露了好几次（破坏者：向 `printf` 提供了错误的数据类型），但暂时假设解决方案仍然不明确，需要进一步调查。
|
||||
|
||||
### 设置断点
|
||||
|
||||
一旦你的代码被加载到 GDB 中，你就可以向 GDB 询问到目前为止代码所产生的数据。要尝试数据自省，通过再次发出 `start` 命令来重新启动你的应用程序，然后进行到第 11 行。一个快速到达 11 行的简单方法是设置一个寻找特定行号的断点：
|
||||
|
||||
```
|
||||
(gdb) start
|
||||
The program being debugged has been started already.
|
||||
Start it from the beginning? (y or n) y
|
||||
Temporary breakpoint 2 at 0x400a48: file debug.cpp, line 9.
|
||||
Starting program: /home/sek/demo/debuggy
|
||||
|
||||
Temporary breakpoint 2, main () at debug.cpp:9
|
||||
9 srand (time(NULL));
|
||||
(gdb) break 11
|
||||
Breakpoint 3 at 0x400a74: file debug.cpp, line 11.
|
||||
```
|
||||
|
||||
建立断点后，用 `continue` 继续执行：
|
||||
|
||||
```
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
|
||||
Breakpoint 3, main () at debug.cpp:11
|
||||
11 cout << "Hello world." << endl;
|
||||
(gdb)
|
||||
```
|
||||
|
||||
现在暂停在第 11 行，就在 `alpha` 变量被设置之后，以及 `beta` 被设置之前。
|
||||
|
||||
### 用 GDB 进行变量自省
|
||||
|
||||
要查看一个变量的值，使用 `print` 命令。在这个示例代码中，`alpha` 的值是随机的，所以你的实际结果可能与我的不同：
|
||||
|
||||
```
|
||||
(gdb) print alpha
|
||||
$1 = 3
|
||||
(gdb)
|
||||
```
|
||||
|
||||
当然，你无法看到一个尚未建立的变量的值：
|
||||
|
||||
```
|
||||
(gdb) print beta
|
||||
$2 = 0
|
||||
```
|
||||
|
||||
|
||||
### 使用流程控制
|
||||
|
||||
要继续进行，你可以步进代码行来到达将 `beta` 设置为一个值的位置：
|
||||
|
||||
```
|
||||
(gdb) next
|
||||
Hello world.
|
||||
12 int beta = 2;
|
||||
(gdb) next
|
||||
14 printf("alpha is set to is %s\n", alpha);
|
||||
(gdb) print beta
|
||||
$3 = 2
|
||||
```
|
||||
|
||||
另外，你也可以设置一个观察点，它就像断点一样，是一种控制 GDB 执行代码流程的方法。在这种情况下，你知道 `beta` 变量应该设置为 `2`，所以你可以设置一个观察点，当 `beta` 的值发生变化时提醒你：
|
||||
|
||||
```
|
||||
(gdb) watch beta > 0
|
||||
Hardware watchpoint 5: beta > 0
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
|
||||
Breakpoint 3, main () at debug.cpp:11
|
||||
11 cout << "Hello world." << endl;
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
Hello world.
|
||||
|
||||
Hardware watchpoint 5: beta > 0
|
||||
|
||||
Old value = false
|
||||
New value = true
|
||||
main () at debug.cpp:14
|
||||
14 printf("alpha is set to is %s\n", alpha);
|
||||
(gdb)
|
||||
```
|
||||
|
||||
你可以用 `next` 手动步进完成代码的执行，或者你可以用断点、观察点和捕捉点来控制代码的执行。
|
||||
|
||||
### 用 GDB 分析数据
|
||||
|
||||
你可以以不同格式查看数据。例如，以八进制值查看 `beta` 的值：
|
||||
|
||||
```
|
||||
(gdb) print /o beta
|
||||
$4 = 02
|
||||
```
|
||||
|
||||
要查看其在内存中的地址：
|
||||
|
||||
```
|
||||
(gdb) print /o beta
|
||||
$5 = 0x2
|
||||
```
|
||||
|
||||
你也可以看到一个变量的数据类型：
|
||||
|
||||
```
|
||||
(gdb) whatis beta
|
||||
type = int
|
||||
```
|
||||
|
||||
### 用 GDB 解决错误
|
||||
|
||||
这种自省不仅能让你更好地了解什么代码正在执行，还能让你了解它是如何执行的。在这个例子中，对变量运行的 `whatis` 命令给了你一个线索，即你的 `alpha` 和 `beta` 变量是整数，这可能会唤起你对 `printf` 语法的记忆，使你意识到在你的 `printf` 语句中，你必须使用 `%d` 来代替 `%s`。做了这个改变，就可以让应用程序按预期运行，没有更明显的错误存在。
|
||||
|
||||
当代码编译后发现有 bug 存在时，特别令人沮丧，但最棘手的 bug 就是这样，如果它们很容易被发现，那它们就不是 bug 了。使用 GDB 是猎取并消除它们的一种方法。
|
||||
|
||||
### 下载我们的速查表
|
||||
|
||||
生活的真相就是这样，即使是最基本的编程，代码也会有 bug。并不是所有的错误都会导致应用程序无法运行（甚至无法编译），也不是所有的错误都是由错误的代码引起的。有时，bug 是基于一个特别有创意的用户所做的意外的选择组合而间歇性发生的。有时，程序员从他们自己的代码中使用的库中继承了 bug。无论原因是什么，bug 基本上无处不在，程序员的工作就是发现并消除它们。
|
||||
|
||||
GNU 调试器是一个寻找 bug 的有用工具。你可以用它做的事情比我在本文中演示的要多得多。你可以通过 GNU Info 阅读器来了解它的许多功能：
|
||||
|
||||
```
|
||||
$ info gdb
|
||||
```
|
||||
|
||||
无论你是刚开始学习 GDB 还是专业人员的，提醒一下你有哪些命令是可用的，以及这些命令的语法是什么，都是很有帮助的。
|
||||
|
||||
- [下载 GDB 速查表][5]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/21/3/debug-code-gdb
|
||||
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/mistake_bug_fix_find_error.png?itok=PZaz3dga (magnifying glass on computer screen, finding a bug in the code)
|
||||
[2]: https://www.gnu.org/software/gdb/
|
||||
[3]: https://opensource.com/article/20/8/printf
|
||||
[4]: https://linux.cn/article-12985-1.html
|
||||
[5]: https://opensource.com/downloads/gnu-debugger-cheat-sheet
|
||||
@ -0,0 +1,205 @@
|
||||
[#]: subject: (How to use Poetry to manage your Python projects on Fedora)
|
||||
[#]: via: (https://fedoramagazine.org/how-to-use-poetry-to-manage-your-python-projects-on-fedora/)
|
||||
[#]: author: (Kader Miyanyedi https://fedoramagazine.org/author/moonkat/)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
如何在 Fedora 上使用 Poetry 来管理你的 Python 项目？
|
||||
======
|
||||
|
||||
![Python & Poetry on Fedora][1]
|
||||
|
||||
Python 开发人员经常创建一个新的虚拟环境来分离项目依赖，然后用 _pip、pipenv_ 等工具来管理它们。Poetry 是一个简化 Python 中依赖管理和打包的工具。这篇文章将向你展示如何在 Fedora 上使用 Poetry 来管理你的 Python 项目。
|
||||
|
||||
与其他工具不同，Poetry 只使用一个配置文件来进行依赖管理、打包和发布。这消除了对不同文件的需求，如 _Pipfile、MANIFEST.in、setup.py_ 等。这也比使用多个工具更快。
|
||||
|
||||
下面详细介绍一下开始使用 Poetry 时使用的命令。
|
||||
|
||||
### **在 Fedora 上安装 Poetry**
|
||||
|
||||
如果你已经使用 Fedora 32 或以上版本，你可以使用这个命令直接从命令行安装 Poetry：
|
||||
|
||||
```
|
||||
$ sudo dnf install poetry
|
||||
```
|
||||
|
||||
```
|
||||
编者注：在 Fedora Silverblue 或 CoreOs上，Python 3.9.2 是核心提交的一部分，你可以用下面的命令安装 Poetry：
|
||||
```
|
||||
|
||||
rpm-ostree install poetry
|
||||
|
||||
|
||||
### 初始化一个项目
|
||||
|
||||
使用 _new_ 命令创建一个新项目。
|
||||
|
||||
```
|
||||
$ poetry new poetry-project
|
||||
```
|
||||
|
||||
The structure of a project created with Poetry looks like this:
|
||||
用 Poetry 创建的项目结构是这样的：
|
||||
|
||||
```
|
||||
├── poetry_project
|
||||
│ └── init.py
|
||||
├── pyproject.toml
|
||||
├── README.rst
|
||||
└── tests
|
||||
├── init.py
|
||||
└── test_poetry_project.py
|
||||
```
|
||||
|
||||
Poetry 使用 _pyproject.toml_ 来管理项目的依赖。最初，这个文件看起来类似于这样：
|
||||
|
||||
```
|
||||
[tool.poetry]
|
||||
name = "poetry-project"
|
||||
version = "0.1.0"
|
||||
description = ""
|
||||
authors = ["Kadermiyanyedi <kadermiyanyedi@hotmail.com>"]
|
||||
|
||||
[tool.poetry.dependencies]
|
||||
python = "^3.9"
|
||||
|
||||
[tool.poetry.dev-dependencies]
|
||||
pytest = "^5.2"
|
||||
|
||||
[build-system]
|
||||
requires = ["poetry>=0.12"]
|
||||
build-backend = "poetry.masonry.api"
|
||||
```
|
||||
|
||||
这个文件包含 4 个部分：
|
||||
|
||||
* 第一部分包含描述项目的信息，如项目名称、项目版本等。
|
||||
* 第二部分包含项目的依赖。这些依赖是构建项目所必需的。
|
||||
* 第三部分包含开发依赖。
|
||||
* 第四部分描述的是符合 [PEP 517][2] 的构建系统。
|
||||
|
||||
|
||||
|
||||
|
||||
如果你已经有一个项目，或者创建了自己的项目文件夹，并且你想使用 Poetry，请在你的项目中运行 _init_ 命令。
|
||||
|
||||
```
|
||||
$ poetry init
|
||||
```
|
||||
|
||||
在这个命令之后，你会看到一个交互式的 shell 来配置你的项目。
|
||||
|
||||
### 创建一个虚拟环境
|
||||
|
||||
如果你想创建一个虚拟环境或激活一个现有的虚拟环境，请使用以下命令：
|
||||
|
||||
```
|
||||
$ poetry shell
|
||||
```
|
||||
|
||||
Poetry 默认在 _/home/username/.cache/pypoetry_ 项目中创建虚拟环境。你可以通过编辑 poetry 配置来更改默认路径。使用下面的命令查看配置列表：
|
||||
|
||||
```
|
||||
$ poetry config --list
|
||||
|
||||
cache-dir = "/home/username/.cache/pypoetry"
|
||||
virtualenvs.create = true
|
||||
virtualenvs.in-project = true
|
||||
virtualenvs.path = "{cache-dir}/virtualenvs"
|
||||
```
|
||||
|
||||
修改 _virtualenvs.in-project_ 配置变量，在项目目录下创建一个虚拟环境。Poetry 命令是：
|
||||
|
||||
```
|
||||
$ poetry config virtualenv.in-project true
|
||||
```
|
||||
|
||||
### 添加依赖
|
||||
|
||||
使用 _poetry add_ 命令为项目安装一个依赖。
|
||||
|
||||
```
|
||||
$ poetry add django
|
||||
```
|
||||
|
||||
你可以使用带有 _-dev_ 选项的 _add_ 命令来识别任何只用于开发环境的依赖。
|
||||
|
||||
```
|
||||
$ poetry add black --dev
|
||||
```
|
||||
|
||||
**add** 命令会创建一个 _poetry.lock_ 文件，用来跟踪软件包的版本。如果 _poetry.lock_ 文件不存在，那么会安装 _pyproject.toml_ 中所有依赖项的最新版本。如果 _poetry.lock_ 存在，Poetry 会使用文件中列出的确切版本，以确保每个使用这个项目的人的软件包版本是一致的。
|
||||
|
||||
使用 poetry _install_ 命令来安装当前项目中的所有依赖。
|
||||
|
||||
```
|
||||
$ poetry install
|
||||
```
|
||||
|
||||
通过使用 _no-dev_ 选项防止安装开发依赖。
|
||||
|
||||
```
|
||||
$ poetry install --no-dev
|
||||
```
|
||||
|
||||
### 列出软件包
|
||||
|
||||
_show_ 命令会列出所有可用的软件包。_tree_ 选项将以树状列出软件包。
|
||||
|
||||
```
|
||||
$ poetry show --tree
|
||||
|
||||
django 3.1.7 A high-level Python Web framework that encourages rapid development and clean, pragmatic design.
|
||||
├── asgiref >=3.2.10,<4
|
||||
├── pytz *
|
||||
└── sqlparse >=0.2.2
|
||||
```
|
||||
|
||||
包含软件包名称，以列出特定软件包的详细信息。
|
||||
|
||||
```
|
||||
$ poetry show requests
|
||||
|
||||
name : requests
|
||||
version : 2.25.1
|
||||
description : Python HTTP for Humans.
|
||||
|
||||
dependencies
|
||||
- certifi >=2017.4.17
|
||||
- chardet >=3.0.2,<5
|
||||
- idna >=2.5,<3
|
||||
- urllib3 >=1.21.1,<1.27
|
||||
```
|
||||
|
||||
最后，如果你想知道软件包的最新版本，你可以通过 _latest_ 选项。
|
||||
|
||||
```
|
||||
$ poetry show --latest
|
||||
|
||||
idna 2.10 3.1 Internationalized Domain Names in Applications
|
||||
asgiref 3.3.1 3.3.1 ASGI specs, helper code, and adapters
|
||||
```
|
||||
|
||||
### 更多信息
|
||||
|
||||
Poetry 的更多详情可在[文档][3]中获取。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://fedoramagazine.org/how-to-use-poetry-to-manage-your-python-projects-on-fedora/
|
||||
|
||||
作者：[Kader Miyanyedi][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://fedoramagazine.org/author/moonkat/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://fedoramagazine.org/wp-content/uploads/2021/03/Poetry_Python-816x345.jpg
|
||||
[2]: https://www.python.org/dev/peps/pep-0517/
|
||||
[3]: https://python-poetry.org/docs/
|
||||
Loading…
Reference in New Issue
Block a user