Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #198039 > unrolled thread

Best practise for managing Conda environments?

Back to article view | Back to comp.lang.python

Contents

  Best practise for managing Conda environments? Martin Schöön <martin.schoon@gmail.com> - 2026-09-21 09:17 +0000
    Re: Best practise for managing Conda environments? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-21 17:32 +0800
      Re: Best practise for managing Conda environments? Martin Schöön <martin.schoon@gmail.com> - 2026-09-21 20:33 +0000
        Re: Best practise for managing Conda environments? Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-09-21 22:05 +0000
          Re: Best practise for managing Conda environments? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-22 14:37 +0800
            Re: Best practise for managing Conda environments? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-22 07:33 +0000
            Re: Best practise for managing Conda environments? Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-09-22 09:08 +0000
              Re: Best practise for managing Conda environments? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-22 22:53 +0800
    Re: Best practise for managing Conda environments? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-22 15:08 +0800
    Re: Best practise for managing Conda environments? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 07:44 +0000
      Re: Best practise for managing Conda environments? "Loris Bennett" <loris.bennett@fu-berlin.de> - 2026-09-22 10:14 +0200
    Re: Best practise for managing Conda environments? Martin Schöön <martin.schoon@gmail.com> - 2026-09-22 19:53 +0000
      Re: Best practise for managing Conda environments? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-23 04:57 +0800
        Formatting (was: Best practise for managing Conda environments?) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-23 08:17 +0000
          Re: Formatting Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-23 20:08 +0800
            Re: Formatting ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-23 12:42 +0000
              Re: Formatting ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-23 14:43 +0000
                Re: Formatting ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-23 15:01 +0000
            Re: Formatting ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-23 13:38 +0000
          Re: Formatting (was: Best practise for managing Conda environments?) Martin Schöön <martin.schoon@gmail.com> - 2026-09-24 08:31 +0000
            Re: Formatting (was: Best practise for managing Conda environments?) Martin Schöön <martin.schoon@gmail.com> - 2026-09-25 08:53 +0000

Page 1 of 2  [1] 2  Next page →

#198039 — Best practise for managing Conda environments?

I am a occasional Python user and hence only post here rather seldom.
Full time lurker though :-)

I am a full time Linux user and moved from pip to conda for managing
my Python life a few years ago. I am not an advanced conda user by
any measure. For the most part moving to conda was a good idea.

Yesterday, however, I encountered a problem that a quick internet
search told me is somewhat common: adding a package to an environment
stalls at the 'solving environment' stage. I found a bunch of rather
different 'fixes'. I have not tried any yet. I think maybe I am doing
environments wrong.

Among the 'fixes' suggested are:

* Use mamba for installing packages.
* conda config --set channel_priority strict
* Remove and re-create environments to ensure packages are up-to-date.

The last one was not stated explicitly. I created it by
'interpreting' several posts that made me think I have done environments
the wrong way.

My thinking now:

I should have more rather than fewer environments and make them more
task specific -- avoid 'general purpose' environments to limit the
number of packages in each environment.

I have noticed that "conda update whatever" /always/ tells me everything
is up-to-date. This can't be true. Will the procedure of the third
bullet above solve this?

No, I have not tried asking any LLM. I hope for some real human advice.

TIA

/Martin

[toc] | [next] | [standalone]

#198040

On 9/21/2026 5:17 PM, Martin Schöön wrote:
> I am a occasional Python user and hence only post here rather seldom.
> Full time lurker though :-)
> 
> I am a full time Linux user and moved from pip to conda for managing
> my Python life a few years ago. I am not an advanced conda user by
> any measure. For the most part moving to conda was a good idea.
> 
> Yesterday, however, I encountered a problem that a quick internet
> search told me is somewhat common: adding a package to an environment
> stalls at the 'solving environment' stage. I found a bunch of rather
> different 'fixes'. I have not tried any yet. I think maybe I am doing
> environments wrong.
> 
> Among the 'fixes' suggested are:
> 
> * Use mamba for installing packages.
> * conda config --set channel_priority strict
> * Remove and re-create environments to ensure packages are up-to-date.
> 
> The last one was not stated explicitly. I created it by
> 'interpreting' several posts that made me think I have done environments
> the wrong way.
> 
> My thinking now:
> 
> I should have more rather than fewer environments and make them more
> task specific -- avoid 'general purpose' environments to limit the
> number of packages in each environment.
> 
> I have noticed that "conda update whatever" /always/ tells me everything
> is up-to-date. This can't be true. Will the procedure of the third
> bullet above solve this?
> 
> No, I have not tried asking any LLM. I hope for some real human advice.
> 
> TIA
> 
> /Martin

Dear Martin,

Sadly, I am completely unfamiliar with Conda, nor do I know anything
about managing Python environments yet.  So I only have a suggestion
for the intermesso [0], and hopefully the wizards of comp.lang.python
have a better answer.

Have you considered installing the offending package using your opera-
ting system package manager instead, if available as such?  There are
n+1 [1] Linux package managers, so I leave off any suggestions for the
command line tool.


Best wishes, and happy Python!

[0] I simply presume someone is listening to music while we wait for the
wizards to reply.

[1] Somewhere, someone is coding a Linux package manager from scratch,
hence if there are /n/ today, there will be /n+1/ tomorrow.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via XS News
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#198042

Den 2026-09-21 skrev Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>:
> On 9/21/2026 5:17 PM, Martin Schöön wrote:
<snip>
>> 
>> Yesterday, however, I encountered a problem that a quick internet
>> search told me is somewhat common: adding a package to an environment
>> stalls at the 'solving environment' stage. I found a bunch of rather
>> different 'fixes'. I have not tried any yet. I think maybe I am doing
>> environments wrong.
>> 
<snip>
>> My thinking now:
>> 
>> I should have more rather than fewer environments and make them more
>> task specific -- avoid 'general purpose' environments to limit the
>> number of packages in each environment.
>> 
>> I have noticed that "conda update whatever" /always/ tells me everything
>> is up-to-date. This can't be true. Will the procedure of the third
>> bullet above solve this?
>> 
>> No, I have not tried asking any LLM. I hope for some real human advice.
>> 
> Dear Martin,
<snip>
> Have you considered installing the offending package using your opera-
> ting system package manager instead, if available as such?  There are
> n+1 [1] Linux package managers, so I leave off any suggestions for the
> command line tool.
>
I think this is how most or even all Linux users start with Python. Then,
after a while you want to use a Python package (or version) not catered
for by your system package manager...

/Martin

[toc] | [prev] | [next] | [standalone]

#198043

On 2026-09-21, Martin Schöön <martin.schoon@gmail.com> wrote:
> Den 2026-09-21 skrev Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>:
>> On 9/21/2026 5:17 PM, Martin Schöön wrote:
><snip>
>>> 
>>> Yesterday, however, I encountered a problem that a quick internet
>>> search told me is somewhat common: adding a package to an environment
>>> stalls at the 'solving environment' stage. I found a bunch of rather
>>> different 'fixes'. I have not tried any yet. I think maybe I am doing
>>> environments wrong.
>>> 
><snip>
>>> My thinking now:
>>> 
>>> I should have more rather than fewer environments and make them more
>>> task specific -- avoid 'general purpose' environments to limit the
>>> number of packages in each environment.
>>> 
>>> I have noticed that "conda update whatever" /always/ tells me everything
>>> is up-to-date. This can't be true. Will the procedure of the third
>>> bullet above solve this?
>>> 
>>> No, I have not tried asking any LLM. I hope for some real human advice.
>>> 
>> Dear Martin,
><snip>
>> Have you considered installing the offending package using your opera-
>> ting system package manager instead, if available as such?  There are
>> n+1 [1] Linux package managers, so I leave off any suggestions for the
>> command line tool.
>
> I think this is how most or even all Linux users start with Python. Then,
> after a while you want to use a Python package (or version) not catered
> for by your system package manager...

Indeed. Using the operating system package manager for Python
packages is only feasible if you yourself are creating a package
for that operating system.

[toc] | [prev] | [next] | [standalone]

#198044

On 9/22/2026 6:05 AM, Jon Ribbens wrote:
> On 2026-09-21, Martin Schöön <martin.schoon@gmail.com> wrote:
>> Den 2026-09-21 skrev Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>:
>>> On 9/21/2026 5:17 PM, Martin Schöön wrote:
>> <snip>
>>>>
>>>> Yesterday, however, I encountered a problem that a quick internet
>>>> search told me is somewhat common: adding a package to an environment
>>>> stalls at the 'solving environment' stage. I found a bunch of rather
>>>> different 'fixes'. I have not tried any yet. I think maybe I am doing
>>>> environments wrong.
>>>>
>> <snip>
>>>> My thinking now:
>>>>
>>>> I should have more rather than fewer environments and make them more
>>>> task specific -- avoid 'general purpose' environments to limit the
>>>> number of packages in each environment.
>>>>
>>>> I have noticed that "conda update whatever" /always/ tells me everything
>>>> is up-to-date. This can't be true. Will the procedure of the third
>>>> bullet above solve this?
>>>>
>>>> No, I have not tried asking any LLM. I hope for some real human advice.
>>>>
>>> Dear Martin,
>> <snip>
>>> Have you considered installing the offending package using your opera-
>>> ting system package manager instead, if available as such?  There are
>>> n+1 [1] Linux package managers, so I leave off any suggestions for the
>>> command line tool.
>>
>> I think this is how most or even all Linux users start with Python. Then,
>> after a while you want to use a Python package (or version) not catered
>> for by your system package manager...
> 
> Indeed. Using the operating system package manager for Python
> packages is only feasible if you yourself are creating a package
> for that operating system.

Point taken.  Now, what is worrying me, is the lack of answers about the
Conda package manager.  I was under the impression Usenet was full of
Python coders [1], and someone would know what to do about the original
problem.

Is there really, in all of Usenet, nobody who knows how to solve this?


[1] Because some people are always talking about Python in comp.lang.c,
and comp.lang.lisp.  No need to name them as they haven't commented in
this discussion thread.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via XS News
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#198047

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>Point taken.  Now, what is worrying me, is the lack of answers about the
>Conda package manager.  I was under the impression Usenet was full of
>Python coders [1], and someone would know what to do about the original
>problem.

  The OP wrote, "I hope for some real human advice.". I'm
  a nerd, so I was out. - Usenet is not what it used to be.
  Most participants first moved to something with E-mail 
  and then to something with JavaScript.

[toc] | [prev] | [next] | [standalone]

#198050

On 2026-09-22, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
> On 9/22/2026 6:05 AM, Jon Ribbens wrote:
>> On 2026-09-21, Martin Schöön <martin.schoon@gmail.com> wrote:
>>> Den 2026-09-21 skrev Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>:
>>>> On 9/21/2026 5:17 PM, Martin Schöön wrote:
>>> <snip>
>>>>>
>>>>> Yesterday, however, I encountered a problem that a quick internet
>>>>> search told me is somewhat common: adding a package to an environment
>>>>> stalls at the 'solving environment' stage. I found a bunch of rather
>>>>> different 'fixes'. I have not tried any yet. I think maybe I am doing
>>>>> environments wrong.
>>>>>
>>> <snip>
>>>>> My thinking now:
>>>>>
>>>>> I should have more rather than fewer environments and make them more
>>>>> task specific -- avoid 'general purpose' environments to limit the
>>>>> number of packages in each environment.
>>>>>
>>>>> I have noticed that "conda update whatever" /always/ tells me everything
>>>>> is up-to-date. This can't be true. Will the procedure of the third
>>>>> bullet above solve this?
>>>>>
>>>>> No, I have not tried asking any LLM. I hope for some real human advice.
>>>>>
>>>> Dear Martin,
>>> <snip>
>>>> Have you considered installing the offending package using your opera-
>>>> ting system package manager instead, if available as such?  There are
>>>> n+1 [1] Linux package managers, so I leave off any suggestions for the
>>>> command line tool.
>>>
>>> I think this is how most or even all Linux users start with Python. Then,
>>> after a while you want to use a Python package (or version) not catered
>>> for by your system package manager...
>> 
>> Indeed. Using the operating system package manager for Python
>> packages is only feasible if you yourself are creating a package
>> for that operating system.
>
> Point taken.  Now, what is worrying me, is the lack of answers about the
> Conda package manager.  I was under the impression Usenet was full of
> Python coders [1], and someone would know what to do about the original
> problem.
>
> Is there really, in all of Usenet, nobody who knows how to solve this?

I've been using Python for nearly 30 years, but I'm afraid I've never
heard of this 'conda' thing of which you speak. I use 'pip' for nearly
everything, but apparently 'uv' is the new hotness.

[toc] | [prev] | [next] | [standalone]

#198051

On 9/22/2026 5:08 PM, Jon Ribbens wrote:
> On 2026-09-22, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
>> On 9/22/2026 6:05 AM, Jon Ribbens wrote:
>>> On 2026-09-21, Martin Schöön <martin.schoon@gmail.com> wrote:
>>>> Den 2026-09-21 skrev Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>:
>>>>> On 9/21/2026 5:17 PM, Martin Schöön wrote:
>>>> <snip>
>>>>>>
>>>>>> Yesterday, however, I encountered a problem that a quick internet
>>>>>> search told me is somewhat common: adding a package to an environment
>>>>>> stalls at the 'solving environment' stage. I found a bunch of rather
>>>>>> different 'fixes'. I have not tried any yet. I think maybe I am doing
>>>>>> environments wrong.
>>>>>>
>>>> <snip>
>>>>>> My thinking now:
>>>>>>
>>>>>> I should have more rather than fewer environments and make them more
>>>>>> task specific -- avoid 'general purpose' environments to limit the
>>>>>> number of packages in each environment.
>>>>>>
>>>>>> I have noticed that "conda update whatever" /always/ tells me everything
>>>>>> is up-to-date. This can't be true. Will the procedure of the third
>>>>>> bullet above solve this?
>>>>>>
>>>>>> No, I have not tried asking any LLM. I hope for some real human advice.
>>>>>>
>>>>> Dear Martin,
>>>> <snip>
>>>>> Have you considered installing the offending package using your opera-
>>>>> ting system package manager instead, if available as such?  There are
>>>>> n+1 [1] Linux package managers, so I leave off any suggestions for the
>>>>> command line tool.
>>>>
>>>> I think this is how most or even all Linux users start with Python. Then,
>>>> after a while you want to use a Python package (or version) not catered
>>>> for by your system package manager...
>>>
>>> Indeed. Using the operating system package manager for Python
>>> packages is only feasible if you yourself are creating a package
>>> for that operating system.
>>
>> Point taken.  Now, what is worrying me, is the lack of answers about the
>> Conda package manager.  I was under the impression Usenet was full of
>> Python coders [1], and someone would know what to do about the original
>> problem.
>>
>> Is there really, in all of Usenet, nobody who knows how to solve this?
> 
> I've been using Python for nearly 30 years, but I'm afraid I've never
> heard of this 'conda' thing of which you speak. I use 'pip' for nearly
> everything, but apparently 'uv' is the new hotness.

I've used Python sporadically since roughly 2011.  I used to have nice
O'Reilly books but have chosen not to try to reacquire those.  They're
probably obsolete.

In any case, I've never used Conda either, and have managed so far with
only a few pip installs.


Best wishes, and happy Python!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via XS News
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#198045

On 9/21/2026 5:17 PM, Martin Schöön wrote:
> I am a occasional Python user and hence only post here rather seldom.
> Full time lurker though :-)
> 
> I am a full time Linux user and moved from pip to conda for managing
> my Python life a few years ago. I am not an advanced conda user by
> any measure. For the most part moving to conda was a good idea.
> 
> Yesterday, however, I encountered a problem that a quick internet
> search told me is somewhat common: adding a package to an environment
> stalls at the 'solving environment' stage. I found a bunch of rather
> different 'fixes'. I have not tried any yet. I think maybe I am doing
> environments wrong.
> 
> Among the 'fixes' suggested are:
> 
> * Use mamba for installing packages.
> * conda config --set channel_priority strict
> * Remove and re-create environments to ensure packages are up-to-date.
> 
> The last one was not stated explicitly. I created it by
> 'interpreting' several posts that made me think I have done environments
> the wrong way.
> 
> My thinking now:
> 
> I should have more rather than fewer environments and make them more
> task specific -- avoid 'general purpose' environments to limit the
> number of packages in each environment.
> 
> I have noticed that "conda update whatever" /always/ tells me everything
> is up-to-date. This can't be true. Will the procedure of the third
> bullet above solve this?
> 
> No, I have not tried asking any LLM. I hope for some real human advice.
> 
> TIA
> 
> /Martin

Dear Martin,

The following is a quote from an email that I believe an A.I. agent sent
me in an email, so you need to take it with a grain of salt.

I have no idea if this is helpful.
------------------------------------------------------------------------
Read the conda thread. The stall at 'solving environment' is almost 
always the solver, not the package. conda's classic solver gets much 
slower as the env grows; libmamba (libsolv) became the default in conda 
23.9, with roughly 50-80% improvements in Anaconda's own numbers. Check 
it with: conda config --show solver. If that says classic: conda install 
-n base conda-libmamba-solver, then conda config --set solver libmamba. 
Two things that also shrink the search space: pin the spec 
(numpy=1.15.4, not numpy) and use one channel, conda-forge or defaults, 
not both.

The 'everything is up-to-date' line usually isn't lying about the 
channel it is looking at. conda update X only considers that env's 
configured channels, and it won't move X if that would break something 
else pinned in the env. conda search -c conda-forge X tells you whether 
a newer build exists for the platform at all. That is the check I would 
run before believing it.

On your OS-package-manager suggestion: Martin's pushback is right, and 
I'd go further. Mixing distro Python packages with a conda env is a 
classic way to get the inconsistent env that stalls in the first place. 
Same language, two different installers, no shared record.

I can't post to the list (my outbound to it is blocked), so passing it 
to you in case it's useful for the thread. No ask.

- Honesty
------------------------------------------------------------------------


Best wishes, and happy Python!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via XS News
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#198048

On 21 Sep 2026 09:17:29 GMT, Martin Schöön wrote:

> I am a full time Linux user and moved from pip to conda for managing
> my Python life a few years ago. I am not an advanced conda user by
> any measure. For the most part moving to conda was a good idea.

My impression of Conda is that it’s more suited to Windows/Mac
environments which lack native package management. For example, I
don’t see a package for Conda under Debian -- surely something as
useful as that is made out to be, would be supported. But it’s not.

The most complex piece of third-party Python-based code that I install
is Jupyter, and that goes quite nicely into a virtualenv maintained
with pip.

[toc] | [prev] | [next] | [standalone]

#198049

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

> On 21 Sep 2026 09:17:29 GMT, Martin Schöön wrote:
>
>> I am a full time Linux user and moved from pip to conda for managing
>> my Python life a few years ago. I am not an advanced conda user by
>> any measure. For the most part moving to conda was a good idea.
>
> My impression of Conda is that it’s more suited to Windows/Mac
> environments which lack native package management. For example, I
> don’t see a package for Conda under Debian -- surely something as
> useful as that is made out to be, would be supported. But it’s not.
>
> The most complex piece of third-party Python-based code that I install
> is Jupyter, and that goes quite nicely into a virtualenv maintained
> with pip.

I help run a Linux HPC system at a university and see Conda being used by
research mainly from the life sciences.  I think the main advantage is that
Conda also provides non-Python dependencies, such as CUDA for GPU-processing
or numerical libraries written in C, such as BLAS.  If, as Martin mentions,
you are using Windows or MacOS, this is probably quite helpful.

However, if you are on a Linux machine, the OS packages plus pip within a venv
will, in my experience, get you quite a long way.  That, together with poetry,
has been all I have needed for developing my own software with Python, but
obviously YMMV,

Cheers,

Loris

-- 
This signature is currently under constuction.

[toc] | [prev] | [next] | [standalone]

#198052

Den 2026-09-21 skrev Martin Schöön <martin.schoon@gmail.com>:
<snip>
> Yesterday, however, I encountered a problem that a quick internet
> search told me is somewhat common: adding a package to an environment
> stalls at the 'solving environment' stage. I found a bunch of rather
> different 'fixes'. I have not tried any yet. I think maybe I am doing
> environments wrong.
>
> Among the 'fixes' suggested are:
>
> * Use mamba for installing packages.
> * conda config --set channel_priority strict
> * Remove and re-create environments to ensure packages are up-to-date.
>
<snip>
> My thinking now:
>
> I should have more rather than fewer environments and make them more
> task specific -- avoid 'general purpose' environments to limit the
> number of packages in each environment.

OK guys and gals, I have done some research and think I have answers.
Yes, I have indeed done environments wrong!

The following three are the most concise ones when it comes to advice:
https://nsc.gitlab-pages.liu.se/berzelius-training/managing-conda-environments-best-practices/1.%20concepts/
https://nsc.gitlab-pages.liu.se/berzelius-training/managing-conda-environments-best-practices/2.%20best-practices/
https://msi.umn.edu/getting-started/help/knowledge-base/best-practices-conda

These are also good:
https://techietory.com/managing-python-environments-with-conda/
https://www.whiteboxml.com/blog/the-definitive-guide-to-python-virtual-environments-with-conda
https://thejacksonlaboratory.github.io/bestpractices_workshop/conda.html

TLDR:
* Create task specific environments.
* Use mamba.
* Try, as far as possible, to instal all needed packages in one go.
* Don't mend/tinker with environments. Create new ones instead.
* Document your environments. README.md or something...

I also asked Duck.ai (front end for Mistral Small 4 in my case) for
advise. The results looks like a summary of the information I
linked to. I will post it separately after having read through
and figured out how to format it for usenet news.

/Martin

[toc] | [prev] | [next] | [standalone]

#198053

On 9/23/2026 3:53 AM, Martin Schöön wrote:

> TLDR:
> * Create task specific environments.
> * Use mamba.
> * Try, as far as possible, to instal all needed packages in one go.
> * Don't mend/tinker with environments. Create new ones instead.
> * Document your environments. README.md or something...
> 
> I also asked Duck.ai (front end for Mistral Small 4 in my case) for
> advise. The results looks like a summary of the information I
> linked to. I will post it separately after having read through
> and figured out how to format it for usenet news.
> 
> /Martin

If you're wondering how to format text for Usenet, I like Emacs for this
task.  I then paste into Thunderbird for posting, but that's because I'm
not inclined yet to figure out how to configure GNUS.

I've also experimented with the WordPerfect [1] plain text output, but
have not /mastered/ it for Usenet purposes.


Happy formatting text for Usenet!


[1] 6.2 for DOS, but any version should do.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via XS News
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#198054 — Formatting (was: Best practise for managing Conda environments?)

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>If you're wondering how to format text for Usenet, I like Emacs for this
>task.  I then paste into Thunderbird for posting, but that's because I'm
>not inclined yet to figure out how to configure GNUS.

  To wrap paragraphs, I wrote a script in Python that uses dynamic
  programming to find the globally best wrap and made it available
  to vim via a key mapping. It was used to wrap this paragraph here.

  I am not always satisfied with the results, and so I also format
  many paragraphs manually and do manual hyphenation painstakingly
  looking up German and English words in hyphenation dictionaries.

  I also have written a Python module that also does hyphenation, and
  which I plan to publish one day, but so far the code has not yet
  been cleaned up. This hyphenation uses TeX's hyphenation patterns.

[toc] | [prev] | [next] | [standalone]

#198055 — Re: Formatting

On 9/23/2026 4:17 PM, Stefan Ram wrote:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>> If you're wondering how to format text for Usenet, I like Emacs for this
>> task.  I then paste into Thunderbird for posting, but that's because I'm
>> not inclined yet to figure out how to configure GNUS.
> 
>    To wrap paragraphs, I wrote a script in Python that uses dynamic
>    programming to find the globally best wrap and made it available
>    to vim via a key mapping. It was used to wrap this paragraph here.
> 
>    I am not always satisfied with the results, and so I also format
>    many paragraphs manually and do manual hyphenation painstakingly
>    looking up German and English words in hyphenation dictionaries.
> 
>    I also have written a Python module that also does hyphenation, and
>    which I plan to publish one day, but so far the code has not yet
>    been cleaned up. This hyphenation uses TeX's hyphenation patterns.

Dear Stefan,

You mean you coded up TeX's line breaking algorithm?  Did you do it from
the book /TeX: The Program/, or /Digital Typesetting/?  The latter has a
code bug in the line breaking algorithm in the first edition, that got
me a code bug check -- only $0x1 symbolic dollar -- and I have faith
it's been fixed in the second edition.

I have alas not coded up TeX's hyphenation patterns, and only thought to
use something like -- what was it? -- some project or other that went
into the public domain, and has a database of hyphenated words.  It
should be trivial to run that through SQLite these days.  The name of
the project escapes me at the moment, and it might be hard to find again
without the /title/ due to its age and lack of S.E.O.

The main problem with fixed width text and paragraph line breaks, is the
usual length of the line on computer screens.  I believe it is shorter
than typically used in books.  My memory of checking this is a little
bit off, as it's been a few decades, but I frequently run into words
running off the screen in WordPerfect for DOS.

Now to get perfect line breaks in fixed width text the best method is to
construct the text carefully, and change the words with a thesaurus, and
the word order, and possibly write a completely new sentence.  When I do
this, I usually do this with hyphenation also, and do not care about the
official rules, and just wing it.  The only paragraph I did this in this
followup, is this one.


Best wishes, and happy line breaking algorithms!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via XS News
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#198056 — Re: Formatting

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>On 9/23/2026 4:17 PM, Stefan Ram wrote:
>>I also have written a Python module that also does hyphenation, and
>>which I plan to publish one day, but so far the code has not yet
>>been cleaned up. This hyphenation uses TeX's hyphenation patterns.
>You mean you coded up TeX's line breaking algorithm?

  I did not write this above. I only wrote that I used TeX's
  hyphenation patterns. But these patterns can be used with
  any line-breaking algorithm.

  But in fact, I /did/ implement something very close to TeX's
  line breaking algorithm.

>                                                      Did you do it from
>the book /TeX: The Program/, or /Digital Typesetting/?

  This was in 2024, and I do non remember all details anymore.
  But, frankly, "TeX: The Program" in the end was too
  complicated for me to read, so I think I used more info from
  "Digital Typesetting" and used "TeX: The Program" only for some
  clarifications. I only implemented it for monospaced fonts, and
  omitted some features of TeX adding some features of my own.

>I have alas not coded up TeX's hyphenation patterns, and only thought to

  The hyphenation pattern files are out there for many languages,
  and I just needed code to read and interpret them. This then
  inserts possible hyphenation points into words before they are
  passed to the line breaker.

>Now to get perfect line breaks in fixed width text the best method is to
>construct the text carefully, and change the words with a thesaurus, and
>the word order, and possibly write a completely new sentence.  When I do
>this, I usually do this with hyphenation also, and do not care about the
>official rules, and just wing it.  The only paragraph I did this in this
>followup, is this one.

  Yeah, that's called "bricktext".

  Now, here are my two posts from 2024 with an early version of
  my line breaker.

Newsgroups: comp.text.tex
Subject: TeX's line breaking in the grub sesh
From: ram@zedat.fu-berlin.de (Stefan Ram)
Message-ID: <Lines-20240805135439@ram.dialup.fu-berlin.de>

  During my grub sesh today, I crushed out TeX's line breaking
  in Python in like a hot minute - 36 to be exact. Tryna use
  it for plain text, like, monospaced fonts and whatnot. Natch,
  I stripped it down to the bare bones, but it's still hella
  tight. Already got that "parshape" action goin' on (which
  Knuth-Plass can't hang with, if I'm not trippin'). Next up,
  I'm finna tackle those "discretionary items" - that's gonna be
  gnarly! For sure there's some janky bugs in there, but peep this:

  wrap.py 

source = 'Ich habe das gebackene Profi-Bettuch bereits gesehen. '

active0 =[ 0, 0, 0, 0 ] # previous, position, quality, line_number
active =[ active0 ]
parshape =[ 10, 20, 20, 20, 20, 20, 20, 20 ]

p = 1
while p < len( source ):
    ch = source[ p ]
    if ch == ' ':
        new_active = []
        best_quality = -10000
        best_act = active[ 0 ]
        for act in active:
            a = act[ 1 ]
            line_number = act[ 3 ] 
            target_length = parshape[ line_number ]
            this_length = p - a
            if this_length > target_length:
                pass
            else:
                quality = this_length - target_length
                new_active.append( act )
                if quality > best_quality:
                    best_quality = quality
                    best_act = act
            new_active.append( [ best_act, p, best_quality, best_act[ 3 ]+1 ] )
        active = new_active
    p += 1
    act = active[ -1 ]
buff = []
while act[ 0 ]:
    prev = act[ 0 ]
    buff.append( source[ prev[1]: act[1] ])
    act = prev
for line in reversed( buff ):
    print(line)

  output

Ich habe das
 gebackene Profi-Bettuch
 bereits gesehen.

Newsgroups: comp.text.tex
Subject: Re: TeX's line breaking in the grub sesh
References: <Lines-20240805135439@ram.dialup.fu-berlin.de>
From: ram@zedat.fu-berlin.de (Stefan Ram)
Message-ID: <wrap-20240828192402@ram.dialup.fu-berlin.de>

  Turns out there was still a glitch in the code! The latest
  build now shows a paragraph break with (fingers crossed)
  global optimization, taking parshape into account. Now that
  I've finally squashed the bug, discretionary items haven't
  been baked in yet. That's next on my to-do list though.

  Ironically, lines of the following Python 3.12 source code have NOT
  been wrapped to the 72 characters recommended for Usenet posts!

  main.py

from dataclasses import dataclass
from typing import Optional, List, Iterator
import bisect

source_text = list( ' Lorem ipsum dolor sit amet, consectetur adipiscing elit, '
'sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad '
'minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea '
'commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit '
'esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat '
'non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ' )
                    
parshape =[ 80, 80, 80, 40 ]

@dataclass
class ActiveEntry:
    previous:    Optional[ 'ActiveEntry' ]= None
    position:    int = 0 # position in the text 
    branch:      int = 0 # for future version
    sum_quality: int = 0 # the sum of all "merits" up to this point
    line_number: int = 0 # line started with this (first line = 0)

parshape_length = len( parshape )

def print_up_to( this ):
    '''prints the wrapped paragraph up to the point "this".
    It starts at the back point "this" and then goes forward
    in the text via the linked chain of points. Finally, for
    printing the text in the normal order, it then goes forward
    again.'''
    buff = []
    qual = []
    sum_quality = this.sum_quality
    while this.previous:
        previous = this.previous
        line = source_text[ previous.position: this.position ]
        # print( f'{line = }' )
        buff.append( line )
        qual.append( this.sum_quality )
        this = previous
    start_position = 0
    # we went backwards, but actually want to print in the normal direction
    first = 1
    for i,( line, qual ) in enumerate( zip( reversed( buff ), reversed( qual ))):
        text = ''.join( line[ start_position: ])
        target_length = parshape[ i ]if i < parshape_length else parshape[ -1 ]# dupe!
        output = text
        print( output[ first: ])
        first = 0
        start_position = 1 # skip an initial space or something
    print()
    print( 'Total merits:', sum_quality )
    print()

active0 = ActiveEntry()
    
active_list =[ active0 ]

current_position = 1
source_length = len( source_text )
while current_position < len( source_text ):
    ch = source_text[ current_position ]
    if ch == ' ': # possible breakpoint
        new_active_list = [] # next active list
        best_sum_quality = None # best quality summed across this and previous lines, not yet determined
        best_act = active_list[ 0 ] # preliminary choice
        for active in active_list:
            active_position = active.position
            line_number = active.line_number
            target_length = parshape[ line_number ]if line_number < parshape_length else parshape[ -1 ]# dupe!
            distance = current_position - active_position
            adjustment = target_length - distance
            if adjustment < 0:
                #   "When an active breakpoint a is encountered for which
                #      the line from a to b has an adjustment ratio less 
                #      than -1 (that is, when the line can't be shrunk to 
                #      fit the desired length), breakpoint a is removed 
                #      from the active list."
                pass # do not transfer into the new active list
            else:
                new_active_list.append( active )
                this_line_quality = -adjustment**2
                have_reached_final_space = current_position == source_length - 1 # final ' ' on end of last line 
                if have_reached_final_space: this_line_quality = 0 # arbitrary whitespace at end is accepted
                this_sum_quality = active.sum_quality + this_line_quality
                if \
                best_sum_quality is None or \
                this_sum_quality > best_sum_quality:
                    best_sum_quality = this_sum_quality
                    best_predecessor = active
        if best_sum_quality is not None:
            # make a new active point from current position, linking it to the best active point found
            new_active_list.append( ActiveEntry( previous=best_predecessor, position=current_position, branch=0, sum_quality=best_sum_quality, line_number=best_predecessor.line_number+1 ))
        active_list = new_active_list
    current_position += 1
active = active_list[ -1 ] # the final space

print_up_to( active )

  output

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit
in voluptate velit esse cillum dolore
eu fugiat nulla pariatur. Excepteur
sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt
mollit anim id est laborum.

Total merits: -80

[toc] | [prev] | [next] | [standalone]

#198058 — Re: Formatting

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>Now, here are my two posts from 2024 with an early version of
>my line breaker.

  My full project includes my new markup language with trans-
  formations to HTML and plain text. The next milestone would
  be something I can use to publish my own texts, but I'm not
  yet there because there are still to many features missing
  and too many bugs. 

  Here's an example from the current state:

  The input:

\lang{en}

An expression like $x^y$ is called a power.
You can imagine specific values for $x$ and $y$,
as in $3^2$ or $2^3$.

  . (I have modified my markup for this post as my own syntax is
  not yet stable. So for this post, I used a TeX-like syntax
  instead, also to make it more readable. The line "\lang{en}"
  is modified, and I exchanged my own symbols by "$" above. 
  These were all modifications.)

  The plain text output now is:

                    y                                            
An expression like x  is called a power. You can imagine specific
                           2     3 
values for x and y, as in 3  or 2 .

  . So I have integrated my formulas with the line wrapping, but only
  as a thin "proof of concept" that only handles the single operator
  "^" and one-letter names/numbers in plain text. 

[toc] | [prev] | [next] | [standalone]

#198059 — Re: Formatting

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>. So I have integrated my formulas with the line wrapping, but only
>as a thin "proof of concept" that only handles the single operator
>"^" and one-letter names/numbers in plain text. 

  It is more an MVP, a minimum viable product, as a /proof of concept/
  would be thrown away, but this is intended to be kept and gradually
  extended.

[toc] | [prev] | [next] | [standalone]

#198057 — Re: Formatting

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>                                a database of hyphenated words. 

  For English, the Moby Hyphenation List is available from
  Gutenberg. For German, there's "wortliste.git".

[toc] | [prev] | [next] | [standalone]

#198064 — Re: Formatting (was: Best practise for managing Conda environments?)

Den 2026-09-23 skrev Stefan Ram <ram@zedat.fu-berlin.de>:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>>If you're wondering how to format text for Usenet, I like Emacs for this
>>task.  I then paste into Thunderbird for posting, but that's because I'm
>>not inclined yet to figure out how to configure GNUS.
>
>   To wrap paragraphs, I wrote a script in Python that uses dynamic
>   programming to find the globally best wrap and made it available
>   to vim via a key mapping. It was used to wrap this paragraph here.
>
<snip>

My problem is the unique 'mark up' I need to weed out...

Also, some questionable tips are hiding among the good ones. I will keep
them but add comments. I think it illustrates nicely how careful you
need be when reading LLM produce.

/Martin

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web