• Best practise for managing Conda environments?

    From Martin =?UTF-8?Q?Sch=C3=B6=C3=B6n?=@martin.schoon@gmail.com to comp.lang.python on Mon Sep 21 09:17:29 2026
    From Newsgroup: comp.lang.python

    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
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Johann 'Myrkraverk' Oskarsson@johann@myrkraverk.invalid to comp.lang.python on Mon Sep 21 17:32:32 2026
    From Newsgroup: comp.lang.python

    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 ( ;; ) _:;
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Martin =?UTF-8?Q?Sch=C3=B6=C3=B6n?=@martin.schoon@gmail.com to comp.lang.python on Mon Sep 21 20:33:53 2026
    From Newsgroup: comp.lang.python

    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
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Jon Ribbens@jon+usenet@unequivocal.eu to comp.lang.python on Mon Sep 21 22:05:26 2026
    From Newsgroup: comp.lang.python

    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.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Johann 'Myrkraverk' Oskarsson@johann@myrkraverk.invalid to comp.lang.python on Tue Sep 22 14:37:06 2026
    From Newsgroup: comp.lang.python

    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 ( ;; ) _:;
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Johann 'Myrkraverk' Oskarsson@johann@myrkraverk.invalid to comp.lang.python on Tue Sep 22 15:08:14 2026
    From Newsgroup: comp.lang.python

    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 ( ;; ) _:;
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From ram@ram@zedat.fu-berlin.de (Stefan Ram) to comp.lang.python on Tue Sep 22 07:33:10 2026
    From Newsgroup: comp.lang.python

    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.


    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.lang.python on Tue Sep 22 07:44:30 2026
    From Newsgroup: comp.lang.python

    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 itrCOs more suited to Windows/Mac
    environments which lack native package management. For example, I
    donrCOt see a package for Conda under Debian -- surely something as
    useful as that is made out to be, would be supported. But itrCOs 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.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Loris Bennett@loris.bennett@fu-berlin.de to comp.lang.python on Tue Sep 22 10:14:14 2026
    From Newsgroup: comp.lang.python

    Lawrence DrCOOliveiro <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 itrCOs more suited to Windows/Mac
    environments which lack native package management. For example, I
    donrCOt see a package for Conda under Debian -- surely something as
    useful as that is made out to be, would be supported. But itrCOs 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.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Jon Ribbens@jon+usenet@unequivocal.eu to comp.lang.python on Tue Sep 22 09:08:18 2026
    From Newsgroup: comp.lang.python

    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.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Johann 'Myrkraverk' Oskarsson@johann@myrkraverk.invalid to comp.lang.python on Tue Sep 22 22:53:26 2026
    From Newsgroup: comp.lang.python

    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 ( ;; ) _:;
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Martin =?UTF-8?Q?Sch=C3=B6=C3=B6n?=@martin.schoon@gmail.com to comp.lang.python on Tue Sep 22 19:53:20 2026
    From Newsgroup: comp.lang.python

    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
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Johann 'Myrkraverk' Oskarsson@johann@myrkraverk.invalid to comp.lang.python on Wed Sep 23 04:57:20 2026
    From Newsgroup: comp.lang.python

    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 ( ;; ) _:;
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From ram@ram@zedat.fu-berlin.de (Stefan Ram) to comp.lang.python on Wed Sep 23 08:17:38 2026
    From Newsgroup: comp.lang.python

    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.


    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Johann 'Myrkraverk' Oskarsson@johann@myrkraverk.invalid to comp.lang.python on Wed Sep 23 20:08:51 2026
    From Newsgroup: comp.lang.python

    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 ( ;; ) _:;
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From ram@ram@zedat.fu-berlin.de (Stefan Ram) to comp.lang.python on Wed Sep 23 12:42:24 2026
    From Newsgroup: comp.lang.python

    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


    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From ram@ram@zedat.fu-berlin.de (Stefan Ram) to comp.lang.python on Wed Sep 23 13:38:14 2026
    From Newsgroup: comp.lang.python

    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".


    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From ram@ram@zedat.fu-berlin.de (Stefan Ram) to comp.lang.python on Wed Sep 23 14:43:44 2026
    From Newsgroup: comp.lang.python

    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.


    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From ram@ram@zedat.fu-berlin.de (Stefan Ram) to comp.lang.python on Wed Sep 23 15:01:33 2026
    From Newsgroup: comp.lang.python

    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.


    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Martin =?UTF-8?Q?Sch=C3=B6=C3=B6n?=@martin.schoon@gmail.com to comp.lang.python on Thu Sep 24 08:31:59 2026
    From Newsgroup: comp.lang.python

    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
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Martin =?UTF-8?Q?Sch=C3=B6=C3=B6n?=@martin.schoon@gmail.com to comp.lang.python on Fri Sep 25 08:53:53 2026
    From Newsgroup: comp.lang.python

    Den 2026-09-24 skrev Martin Sch||||n <martin.schoon@gmail.com>:
    <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.

    OK, let's see how I managed. Org-mode kind of markup used:

    * Heading 1
    ** Heading 2
    ~code~
    + list bullet
    *bold*
    /emphasis/

    # Python style inline comment by me.

    ###################################################################

    Mistral Small 4 on bets practice for managing virtual environments
    using conda.

    Managing virtual environments with Conda (Anaconda/Miniconda) is
    essential for isolating project dependencies and avoiding
    conflicts. Here are the best practices. By following these
    practices, you ensure reproducible, conflict-free environments for
    your projects.

    * Create isolated environments
    Always create a dedicated environment for each project to
    avoid dependency conflicts.

    Create a new environment with a specific Python version:

    ~conda create --name my_project python=3.9~

    Activate the environment:

    ~conda activate my_project~

    *Best Practice:*
    + Use descriptive names (e.g., `my_project_dev', `data_science_env').
    + Specify Python versions explicitly (`python=3.9' instead of just
    `python').

    * Export and recreate environments
    To share or replicate an environment, export its dependencies to
    a YAML file.

    Export the environment to a YAML file:

    ~conda env export --name my_project > environment.yml~

    Recreate the environment from the YAML file:

    ~conda env create --file environment.yml~

    *Best Practice:*
    + Commit environment.yml to version control (e.g., Git) for
    reproducibility.
    + Use `conda env export --from-history' to export only explicitly
    installed packages (avoids unnecessary dependencies).

    * Update environments safely
    Avoid breaking dependencies by updating packages carefully.

    Update all packages in the environment:

    ~conda update --all~ # This is /not/ recommended by NSC!

    Update a specific package:

    ~conda update numpy~

    *Best Practice:*
    + Test updates in a staging environment before applying them to
    production.
    + Use `conda list' to check installed versions before updating.

    * Remove unused environments
    Clean up old environments to save disk space.

    List all environments:

    ~conda env list~

    Remove an environment:

    ~conda env remove --name old_env~

    *Best Practice:*
    + Regularly prune unused environments (`conda clean --all' removes
    cached packages).

    * Use conda-forge for additional packages
    Prefer conda-forge for community-maintained packages.

    Add conda-forge as a channel:

    ~conda config --add channels conda-forge~

    Install a package from conda-forge:

    ~conda install some_package~

    *Best Practice:*
    + Prioritize conda-forge over the default Anaconda channel for
    broader package availability.

    * Avoid mixing conda and pip
    If you must use pip, install it first in the Conda environment.

    ~conda install pip~

    ~pip install some_pip_package~

    *Best Practice:*
    + Prefer Conda packages when possible to avoid conflicts.
    + If using pip, document it in environment.yml under `pip:'.

    # According to NSC you should /never/ install packages using conda
    # /after/ you have used pip. Do /all/ conda (mamba) installs before
    # using pip!

    * Use `conda clean' regularly
    Remove unused packages and caches to free up space.

    ~conda clean --all~

    *Best Practice:*
    + Run this periodically to keep your Conda installation lean.

    * Use environment variables for paths
    Set environment variables to avoid hardcoding paths.

    Set a variable in the current shell:

    ~export MY_DATA_DIR=/path/to/data~

    Or set it in the Conda environment:

    ~conda env config vars set MY_DATA_DIR=/path/to/data~

    ~conda activate my_project~

    **Best Practice:**
    + Use `.env` files for project-specific variables (load them with
    `python-dotenv`).

    * Use mamba for faster dependency resolution
    Mamba is a drop-in replacement for Conda that resolves dependencies
    much faster.

    Install mamba:

    ~conda install mamba -n base -c conda-forge~

    Use mamba instead of conda:

    ~mamba install numpy pandas~

    *Best Practice:*
    + Use mamba for large environments to speed up installation.

    * Document dependencies clearly
    Include a README.md in your project with:
    - Environment setup instructions.
    - Key dependencies.
    - How to activate the environment.

    * Example Workflow
    ** Create environment
    ~conda create --name my_project python=3.9~

    ~conda activate my_project~

    ** Install packages
    ~conda install numpy pandas scikit-learn~

    ~pip install some_pip_package~

    ** Export environment
    ~conda env export --from-history > environment.yml~

    ** Share environment
    Share environment.yml and README.md with collaborators.

    ####################################################################

    I hope this is readable.

    Note that some advice above is /not/ good practice according to the instructions supplied by NSC and NCS provides plausible motivation
    for their advice.

    https://nsc.gitlab-pages.liu.se/berzelius-training/managing-conda-environments-best-practices/2.%20best-practices/

    I have tested none of this so far. The weather has been too nice :-)

    /Martin
    --- Synchronet 3.22a-Linux NewsLink 1.2